Plan mode: ignored on already-loaded claude sessions; /plan has no CLI-parity path

[ymichael]

Two related gaps found in a post-#1834 gap-QA pass (plan mode itself works end to end on a FRESH claude session: ExitPlanMode → plan approval interaction → approve → execution):

1. Loaded-session mode switch ignored: sending the structured /plan composer action to an already-loaded claude-code session (acceptEdits mode) did not switch modes — the turn ran normally and applied an edit. After thread stop (forcing a fresh session), the same flow worked. Likely the live-session settings path doesn't apply the permission-mode change to an existing SDK session (same family as Env-var changes cannot rebuild a live provider bridge session (needs a runtime design call) #1720's env-var live-change limitation, but for permission mode).
2. CLI parity: plain-text /plan sent via bb thread tell is not parsed as the composer plan action, so agents/CLI users cannot enter plan mode at all — an instance of the "every end-user feature must be usable via CLI/SDK" rule (AGENTS.md).

Evidence: /tmp/gap-qa.md (item 5) from the 2026-08-19 run.

AGENT GENERATED: by Claude Fable 5

Regression or pre-existing? Undetermined — adjudicate by running the loaded-session /plan probe on a pre-#1834 checkout. The mode-switch plumbing (live session settings vs construction-signature rebuild) predates the cutover, so pre-existing is plausible, but unverified.

[SawyerHood]

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

• Verdict: REPRODUCED · root-cause confidence: high
• Root cause (short): Since Agent providers as a first-class plugin surface (provider bridge protocol) #1640 the bridge-protocol adapter classifies every option change as "live" (no thread/resume), and the Claude bridge's turn/start only uses providerOptions.claudeCodePermissionMode to strip the /plan mention — it never calls session.setPermissionMode("plan") on the loaded SDK session, so the turn runs in the original mode (edit applied); separately, plan mode is keyed solely on a structured command mention that bb thread tell/spawn never produce (mentions: []), so plain-text /plan reaches the Claude CLI which rejects it ("/plan isn't available in this environment").
• Proposed fix: Part 1 (prototype verified, diff saved): in plugins/provider-claude-code forward providerOptions.claudeCodePermissionMode into the bridge turn params (session-params.ts buildClaudeTurnParams + commands.ts claudeTurnStartParamsSchema/claudeTurnSteerParamsSchema), and in bridge.ts runTurnStart/runTurnSteer, after applyLiveSessionSettings, if params.claudeCodePermissionMode === "plan" && threadSession.permissionMode !== "plan" then await session.setPermissionMode("plan") and set threadSession.permissionMode = "plan" (exit stays owned by restoreApprovedPlanPermissionMode / cancel-plan); repro test…
• Caveats: Part 1 is the same defect already reported and root-caused in Claude Plan mode can skip the proposal flow in a mid-conversation thread #1712 (effectively a duplicate); Part 2 (CLI parity) is new. Regression origin determined as Agent providers as a first-class plugin surface (provider bridge protocol) #1640 (not Narrow-grammar provider bridge protocol: bridges emit semantic deltas, the runtime assembles the timeline (v2) #1834) via git log -S. The broader suspicion that other construction-scoped options (generic permission mode picker, permissionScope) are also ignored on a loaded Claude session follows from the same code path but was not separately p…

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