provider-bridge-acp answers fs/write_text_file with result: null, violating the ACP schema (agents report Parse error on every write)

[erwinkn]

Summary

When an ACP agent calls fs/write_text_file, bb's bridge writes the file successfully but replies with "result": null. The ACP schema defines WriteTextFileResponse as an object ({} with optional _meta), so strict ACP decoders reject the response and report Parse error to the user on every write — even though the write succeeded. Expected: return {} per the schema.

Versions and environment

• bb 0.42.1, also present on main at 3526458cd4bc
• @get-bb/plugin-sdk 0.4.47 (bundled provider-bridge-acp)
• Provider: Devin via ACP (devin acp, Devin CLI 3000.6.14+); affects any ACP agent whose decoder validates WriteTextFileResponse strictly
• Linux 6.12.93 (exe.dev VM), bb Connect paired, worktree environment

Steps to reproduce

1. Start a thread with a strict-decoding ACP agent (Devin CLI reproduces it).
2. Have the agent perform any file write or edit tool call, which maps to fs/write_text_file.
3. The file is written correctly, but the agent reports Failed to write file '<path>': Parse error.

Did not reproduce with: fs/read_text_file (returns {content}, a valid object). Agents with lenient decoders presumably don't notice.

Expected vs actual

Actual: after a successful write the bridge sends "result": null; the agent surfaces Parse error (JSON-RPC -32700, produced locally in the agent — no error goes on the wire).

Expected: "result": {} and no error.

Evidence

• responder.result(null) after a successful write: https://github.com/get-bb/bb/blob/3526458cd4bc/packages/provider-bridge-acp/src/bridge/bridge.ts#L1514-L1553
• ACP schema.json v1.21.0: WriteTextFileResponse is type: object with optional _meta only — null is invalid. The ACP "File System" prose doc shows "result": null in its example, contradicting the schema; likely the origin of the bug (worth reporting upstream to the ACP project too).
• Devin's agent-client-protocol crate (util.rs, json_cast) maps the typed decode failure to Error::parse_error().
• Reproduced against the SDK bridge with a scripted strict ACP peer: fails with null, passes with {}. Also confirmed in live Devin threads — every write/edit tool result reads Failed to write file '<path>': Parse error while the file lands correctly.

What you ruled out

• Not a plugin-side workaround: the SDK hard-codes fs capabilities to true, and callers only see the JSON-RPC line.
• Not a wire error: the -32700 is synthesized inside the agent after the response arrives.
• Still on main at 3526458cd4bc.

Suggested priority and effort

Medium — every write/edit tool call reports a spurious error to strict ACP agents; files still write, no data loss; no agent-side workaround. Effort: Low (one-line change to responder.result({})).

AGENT GENERATED — investigation recorded in https://github.com/erwinkn/bb-plugins/blob/main/README.md ; finding produced in a bb thread running Devin over ACP, where the symptom was observed live.

[bb-slop-cop]

🚨 SLOP COP 🚨 · new-issue-autopilot

Classified as Bug · Medium priority · Low effort; added providers, provider-acp, and partial-repro. No existing classification values were replaced.

Reproduction report: PARTIALLY REPRODUCED, high root-cause confidence. In two clean checkouts of trusted main, the filesystem handler persisted both creation and update writes, then returned null; an object-only response check rejected it. The report includes the repeatable handler test. Live Devin behavior and the upstream schema were not independently verified; the normal build was blocked by the local pnpm launcher.

No PR: changing the public ACP wire response is excluded by this rule’s simple-fix conditions.

[SawyerHood]

Consolidating #3560 into this earlier tracker at the owner’s request during the past-week duplicate review.

Same fs/write_text_file response defect: successful writes return null, and strict ACP clients report Parse error. Preserve the later Devin workaround release https://github.com/Alg0rix/bb-plugin-devin/releases/tag/v0.2.1 and reproduction report https://get-bb.github.io/reports/issues/3560.html. These add workaround and independent evidence, not a separate root cause.

The original issue and its comments remain available through the link. Closing the duplicate does not mean this work is fixed or complete.

AGENT GENERATED