Repository navigation
Plan-mode thread started by an agent shows no Implement button or mode control when plan mode is off in settings #29250
Description
What happened
An agent started a thread with t3_thread_launch and interactionMode: "plan". I have plan mode off in settings. The agent proposed a plan twice. I was on the mobile app and found no way to implement it or leave plan mode, so my replies kept the thread in plan mode and its delegate_task calls kept failing with interaction_mode_escalation_denied ("Child interaction mode default is broader than parent mode plan."). On the desktop, after a turn ended with a proposed plan, there was no Implement either: the composer showed only its send button and no mode, and the plan card's menu only offers Copy to clipboard, Download as markdown and Save to workspace.
Diagnosis
resolveComposerInteractionMode (ChatView.logic.ts) returns "default" whenever planModeEnabled is false, whatever the server thread's mode. ChatView passes that to shouldShowPlanFollowUpPrompt, which requires "plan", so Implement and "Implement in a new thread" never render. The server keeps the thread in plan. A desktop send would silently switch it through persistThreadSettingsForNextTurn, but nothing tells you that. Mobile has no Implement action for proposed plans and keeps the thread's mode unless you pick /default. Agents can start plan-mode threads whatever your plan-mode setting is. Unchanged on main.
Steps to reproduce
- Turn plan mode off in settings.
- From an agent thread, call
t3_thread_launchwithinteractionMode: "plan". - Let the agent propose a plan.
- Desktop: no Implement and no mode indicator. Mobile: no Implement.
delegate_taskwithinteractionMode: "default"from that thread is denied.
Version
desktop and server 0.1.5; mobile version unknown.
Environment
macOS 27.2 arm64, Claude provider.
Evidence
The thread row has `creationSource: mcp`, `interaction_mode: plan`, and `proposed_plan` rows with `status: active`. The server trace for the thread shows only `thread.visit`, `message.dispatch` and `runtime-request.respond`, and never `thread.interaction-mode.set`. Desktop, after the turn settled with a proposed plan: the primary control was "Submit message", the accessibility tree had no "Implement" or "Implement in a new thread", and there was no mode chip.Related issues
#5836 (closed): new mobile threads locked in plan mode, closed because /plan and /default exist. This one is the desktop with the setting off, plus threads started by agents.
Fix applied or workaround
/default in the composer, or send any message from the desktop app.
Filed by
Claude Opus 5.5 in T3 Code, following the triage playbook.
Activity
fix: plan-mode threads keep a mode control when plan mode is off
fix: plan-mode threads keep a mode control when plan mode is off
fix: plan-mode threads keep a mode control when plan mode is off
fix: plan-mode threads keep a mode control when plan mode is off
shouryadixitisverycool commentedon Nov 5, 2026
Same bug on 0.1.7 (desktop and server 0.1.7 on Linux x64, Claude provider, claude-opus-5-5), reached from the mobile app.
An agent launched the thread with
t3_thread_launchandinteractionMode: "plan", runtime Full access. Plan mode is off in my settings. The agent calledExitPlanModeand proposed a plan. From mobile I replied "Okay I approve of the plan. Let's get building." That went out as a plan-mode follow-up, so the next run opened the Claude query withpermissionMode: "plan"again. Everyinitin the provider event log showsplan.The agent built the feature anyway. Plan wins over Full access in
permissionModeForClaudeRuntimePolicy, and Plan installs the permission callback, so every Write/Edit raised a file-change approval (8 of them). It also raised command approvals formcp__t3-code__link_pull_requestandmcp__t3-code__t3_thread_send.acceptForSessionon a file change did not stop the next Write from asking (#23918, #24413).Impact: I had told the agent I was going to sleep and wanted it done by morning. One Write approval stayed pending from 21:31 to 05:32 UTC, so the run stalled for 8 hours.
Source:
orchestration_v2_projection_runtime_requestsand the provider event log. PRs that look relevant: #27829, #29267, #29275, #24413.Triaged by Claude Code (claude-opus-5-5) running inside T3 Code.
fix: plan-mode threads keep a mode control when plan mode is off
fix: plan-mode threads keep a mode control when plan mode is off
fix: plan-mode threads keep a mode control when plan mode is off
fix: plan-mode threads keep a mode control when plan mode is off
t3dotgg commentedon Nov 9, 2026
Note
🤖 Claude Opus 5.5 responding on behalf of Theo
Superseded: #33131 merged as 521ac7c. It makes the current behavior the intended one: clients no longer have a Plan mode control or an Implement follow-up. Agent-launched plan threads still show their plan card, and your next message moves the thread to build mode. Verified with
vp run check:changedand green CI on the merged head.shivamhwp commentedon Nov 10, 2026
Closing as superseded by #33131, merged as 521ac7c. Clients no longer have a Plan mode control or an Implement follow-up, and the next message on an agent-launched plan thread moves it to build mode. Reopen if a plan thread still gets stuck on a build that includes that commit.