acp-cursor advertises fork support it does not have; forking births an errored thread

[ymichael]

The provider roster advertises supportsFork: true for acp-cursor, but cursor-agent does not advertise ACP session/fork support, so bb thread fork on a cursor thread births an errored thread (system/error: "does not advertise session/fork support"). The guard itself is correct; the roster capability is wrong for this agent. The ACP fork path works where the agent supports it (verified live on acp-opencode).

Found during the narrow-grammar cutover live QA (branch narrow-grammar-prototype); reproduced byte-identical on origin/main — pre-existing, not a cutover regression. Evidence: /tmp/narrow-grammar-gate.md (finding 2) from that run.

Likely fix direction: the ACP tier should project fork capability per-agent from the agent's advertised sessionCapabilities.fork at initialize time (the bridge already probes it), not from the tier-wide declaration.

AGENT GENERATED: by Claude Fable 5

[SawyerHood]

Reproduction & root-cause report: https://get-bb.github.io/reports/issues/1833.html

• Verdict: REPRODUCED · root-cause confidence: high
• Root cause (short): plugins/provider-acp/server.ts statically declares acp-cursor with fork: "tip" (projected to supportsFork: true for the app and the server's POST /threads/fork gate), but cursor-agent's ACP initialize advertises no sessionCapabilities.fork, so the bridge's honest per-session guard fires only after the fork thread is already created and started; the same tier-wide ACP_TIER_CAPABILITIES.supportsFork=true fallback also misreports acp-grok and every custom ACP agent.
• Proposed fix: Minimal (verified live and by the repro test): change fork: "tip" to fork: "none" in plugins/provider-acp/server.ts; the server then returns HTTP 400 "Provider acp-cursor does not support thread forks" without creating a thread, the app hides "Fork into new thread", and the adapter's declared ceiling rejects thread/fork before spawning the agent. Complete fix: make fork a per-agent declaration for the whole ACP tier (add fork/supportsFork to KnownAcpAgent and the customAcpAgents config schema, default "none", mirroring supportsManualCompaction), resolve it via resolveAcpAgentCapabilitiesForPro…
• Caveats: opencode is not installed here, so the "fork works on acp-opencode" claim was not re-verified. The issue's suggested dynamic derivation (probe agent capabilities at initialize) is not a drop-in: the ACP initialize happens per session inside the bridge after thread creation and there is no daemon-to-server capability channel; that path would need a protocol bump. acp-grok was verified to also lack …

The report has copy-paste repro steps, screenshots where the bug is visual, code permalinks at the base commit, and repro artifacts. It was independently re-run by a second agent (see its Verification section).

AGENT GENERATED: by Claude Opus 5