Repository navigation
[Bug]: Side chat lets users select Full access but silently runs its first turn as Supervised #28110
Description
What happened
When creating an empty side chat from the side panel, the composer lets the user enter a prompt, select a model, and explicitly select Full access before sending. The server nevertheless runs the first turn as Supervised, so the selected permission mode does not describe the permissions actually used.
Reported with Muse Spark / Meta models. Source inspection shows that the first-turn override is provider-independent; other providers have not been reproduced.
Steps to reproduce
- Open a thread and create an empty side chat from the side panel.
- In the side chat, enter a prompt that requires a shell command or file change.
- Select a Muse Spark model and explicitly select Full access in that side chat's composer.
- Send the first message.
- Observe approval requests despite the explicit Full access selection.
Expected behavior
The permission picker should accurately communicate the mode that will govern the turn.
If the first turn must be Supervised, make that restriction visible before sending and prevent the picker from implying that Full access will apply. Alternatively, if an explicit user selection is intended to override the default, honor that selection. The issue is the silent mismatch; it does not require removing the intentional first-turn restriction.
Source evidence
Inspected at commit 79f1fadfc6:
ThreadForkService.tscreates side chats inapproval-requiredmode.ChatView.tsxpersists the explicitly selected runtime mode.ProviderTurnStartService.tsoverrides the effective mode toapproval-requiredfor the side chat's first turn or the turn receiving its initial context, without checking whether the user explicitly selected Full access.ProviderTurnStartService.test.tsexplicitly covers this restriction, including a provider switch, and expects later turns to follow the thread's mode.
The restriction was introduced intentionally in #26901. Its code comment says: "A side chat shares its parent's worktree; the turn that gets its context asks before acting."
Verification limits
The reproduction above is the user's report. The explanation was verified through source, existing tests, and git history. No additional live Muse turn or browser reproduction was performed while filing this issue. The user's installed version was not provided.
Filed on the user's behalf by GPT-6.1 Sol through the Codex harness in T3 Code.
Activity
Wiktor102 commentedon Oct 31, 2026
Additional finding: this can also break follow-up messages in a Muse side chat, beyond the permission-picker mismatch.
Confirmed runtime failure
The user reported a side chat whose follow-up displays:
Read-only inspection of the matching side chat's persisted state and server trace confirms:
muse-spark-1.3-contributor, reasoning effortmax.full-access.2026-10-31T11:37:03.644Z.2026-10-31T11:40:21.062Z.ProviderAdapterTurnStartError, caused byProviderAdapterProtocolErrorwith detailRuntime policy changes require a fresh Muse host.0.1.6-nightly.20261031.3969.Cause
Source inspection at
79f1fadfc6explains the failure:approval-required.full-accessselection.full-access.ProviderSessionManager.openreturns the existing runtime for the session without reconciling its launch-time runtime policy.MuseAdapter.startrejects the turn because its requested mode differs from the host's launch mode.The user does not need to change permissions between messages to trigger this. The first-turn override itself creates the transition from Supervised to the selected Full access mode. The host must be restarted and the native session resumed when this transition requires it.
Provider scope
The first-turn override and the resulting mismatch with the picker are provider-independent. This follow-up failure is confirmed for Muse through the actual server trace.
Other adapters handle permissions differently: Codex supplies approval/sandbox settings per turn, and Claude has session reconfiguration/recreation logic. Those source differences do not establish that every other provider is unaffected. No cross-provider runtime reproduction was performed.
A search found no existing issue or PR specifically tracking this Muse side-chat follow-up failure. #20739 and #23232 concern Muse Auto mode and do not address this transition.
Investigation by GPT-6.1 Sol through the Codex harness in T3 Code.
ignaciomontenegroc commentedon Nov 1, 2026
Additional report with Codex on Windows, collected on 2026-11-01.
Reported behavior
New side chats start in Supervised even though my saved default is Auto, so I have to change the mode manually each time. After selecting Auto or Full access in a side chat, I still encounter repeated permission prompts. Please include Codex in the affected-provider scope of this report.
Verified environment
defaultRuntimeMode: auto. The reporting chat also currently reportsruntimeMode: auto.Sanitized local diagnostics
Read-only inspection of the T3 state database found:
full-access: first run 2026-11-01 09:45:03.281Z–09:46:41.194Z. A command approval request was created at 09:45:12.674Z, and twomcp-elicitationrequests followed during that first run. Its next two runs completed without entries in the runtime-request table.auto: first run 10:01:23.056Z–10:02:29.887Z, with four command approval requests and twomcp-elicitationrequests. Its next two runs completed without entries in that table.approval-required, despite the global Auto default.The saved mode is the mode at diagnostic collection time, not a historical snapshot proving the mode at every earlier request. The before-send mode selection is the user's report. MCP elicitation is listed separately because its presence alone does not establish a shell-approval policy failure.
Matching release source
The release tag
v0.1.6still contains both behaviors:approval-required.approval-required, even when a different mode is saved on the thread.Expected behavior and limits
Remember or honor my preferred mode for new side chats, and make any enforced first-turn restriction clear in the picker before sending. Selecting Auto or Full access should accurately describe the effective permissions, subject to any explicitly disclosed restriction.
These records support the first-turn mismatch tracked here. They do not establish that later Codex turns ignore Full access, and no new agent run was launched to reproduce it during collection. Claude was not tested. Raw databases, conversation text, project paths, credentials and unfiltered logs are not attached.
Related usability request
I would also like one keyboard shortcut that directly opens a new side chat, including when the right panel is closed, without first opening the panel and its New menu.
aoppenh1-afk commentedon Nov 1, 2026
Additional report from T3 Code Desktop
0.1.7-nightly.20261101.4016on macOS arm64.Creating side chats with
/sidestarts them in Supervised mode despite my Full access settings. I encounter this with both Claude Code and Codex.Please provide either a separate default approval setting for side chats or an option to inherit the main thread’s approval mode. Making the first-turn restriction visible would clarify the current behavior, but would not address this preference.
Read-only investigation found both side chats currently stored as
approval-required, with their parent threads stored asfull-access. Source at7195b699547b538e49f758e314dde5c8c5d907cfexplicitly sets that default inThreadForkService.tsand enforces first-turn supervision inProviderTurnStartService.ts.No settings or database records were changed, and no new live provider turn was run during investigation.
Investigated by GPT-6.1 Sol through the Codex harness in T3 Code.
ElliotDrel commentedon Nov 1, 2026
Note
🤖 gpt-6.1-sol responding on behalf of Elliot
Additional observed variant on Windows desktop with Codex / GPT-6.1 Sol: creating a side chat from a parent in Auto mode persisted the child as
approval-required(Supervised). The child then requested approval for a read-only shell search andt3_thread_read. This was verified from local persisted state and the activity API, rather than inferred from the composer label. No explicit permission change was reported by the user.This adds the automatic inheritance/default case to the explicit Full access picker case above. Given the intentional first-turn restriction described in this issue, the UX should explain the mode change before sending and communicate which mode subsequent turns use. This observation does not establish that the intentional restriction itself is a bug.
Private identifiers, local paths, conversation content, and screenshots have been omitted.
ElliotDrel commentedon Nov 1, 2026
Note
🤖 gpt-6.1-sol responding on behalf of Elliot
Clarifying Elliot's requested behavior: a side chat should inherit the current parent thread's permission mode, including its first turn. Creating a side chat should not silently change Auto or Full access to Supervised. If the user explicitly changes the side chat's permissions, honor that selection.
The shared-worktree rationale does not match the behavior Elliot wants: he has already chosen the parent's permissions and expects that choice to carry into the side chat. A warning explaining the forced restriction would not satisfy this request; the requested change is permission inheritance and removal of the unconditional first-turn override.
exgota commentedon Nov 1, 2026
+1. I run full access on everything. Side chats should inherit the parent's mode, first turn included.
If the worktree risk matters, make it a setting: side chat default, inherit or supervised.
jaykaycodes commentedon Nov 3, 2026
Another location, on 0.1.6 and current main, with Claude Code on Linux (server) and the web client.
There are two hardcoded overrides, not one. The server forces the first run (
t3code/apps/server/src/orchestration-v2/ProviderTurnStartService.ts
Lines 706 to 711 in f6503f0
runtimeMode: "approval-required"when it sends a side chat's first message:t3code/apps/web/src/components/chat/useSideChat.ts
Line 73 in f6503f0
The client value is persisted on the thread, so the whole side chat stays Supervised, not just its first turn. In our thread store, every side chat is
approval-requiredwhile all 694 other user and subagent threads arefull-access, which matches our "Default permissions for new threads" setting. The Claude process for each later turn starts with--permission-mode default, againstbypassPermissionsfor normal threads. Subagents a side chat delegates also land inapproval-required.Suggested fix: send the parent thread's runtime mode (or the default from settings) from
useSideChat.tsand drop the server override, or make it a setting as suggested above.KorenKrita commentedon Nov 3, 2026
+1. A side chat should inherit the parent thread's current permission mode, including its first turn.
If I've set the parent to Full access or Auto, opening
/btw//sideshould not quietly drop me to Supervised. Then I get approval prompts for read-only actions such as reading the parent thread. If I explicitly change the mode in the side chat, honor that selection instead.A separate side-chat default (as in #29300) is useful, but I'd like "inherit from parent" to be an option, ideally the default. Forcing Supervised on the first turn defeats the point of a quick aside.
ondrej-merkun commentedon Nov 4, 2026
+1
satyalyadav commentedon Nov 4, 2026
Additional reproduction on
0.1.8-nightly.20261104.4179, with the OpenCode provider.What happened
Created a side chat, set its composer to Full access, and sent the first message. The mode change was accepted and the thread persisted
runtimeMode: "full-access", but the first reply still asked for approval on every shell command and file read.Timeline (UTC, 2026-11-04)
approval-requiredthread.runtime-mode.settofull-accessaccepted, thread projection updatedcommandapproval request; 5 more command requests and 2file-readrequests followed through 19:33:13.804The live OpenCode session had
shell * ask,edit * ask, andexternal_directory * askrules installed while the thread said Full access, so the provider received the supervised policy.Environment
opencode-go/deepseek-v4.1-flashSource
At release commit
9e85538for this build,apps/server/src/orchestration-v2/ProviderTurnStartService.ts(around line 703) replaces the thread mode withapproval-requiredfor a side chat's first run or a run receiving its initial context. It does not check whether the user chose Full access.apps/server/src/orchestration-v2/ThreadForkService.tsline 117 creates side chats inapproval-required.The docs already say a side chat's first reply asks before acting, so the restriction may be intended. The bug is that the picker reports Full access and the server silently uses Supervised.
Still present on
mainas of commit95e53a5.Reported by DeepSeek V4.1 Flash through a T3 Code triage session.
hamu-dev commentedon Nov 6, 2026
Confirmed, and I traced the mechanism in source at main
337c5858. The desktop app, the local server, and the linked environment's server all run0.1.8-nightly.20261105.4205.Three choices combine here:
The client hardcodes the first turn's mode.
apps/web/src/components/chat/useSideChat.tsstarts every side chat turn 1 withruntimeMode: "approval-required", whatever the picker shows.Pi keeps one mode for the life of the session.
packages/provider-pi/src/server/adapter.tsdeclaressupportsRuntimeModeSwitchInSession: false, documented as "Restart on mode changes so the permission hook retains one immutable lifetime policy". Switching the picker to Full access affects turn 2, after the restart. The running turn staysapproval-required.Pi's injected hook exempts only read-only-annotated tools. In
packages/provider-pi/src/server/mcpExtensionSource.ts, thepi.on("tool_call", …)handler returns early only forfull-access, known read-only builtins, or MCP tools withreadOnlyHint: true. Everything else prompts.Also,
t3_thread_read, which the UI shows as "Reading thread", is annotatedTool.Readonly, falseinapps/server/src/mcp/toolkits/orchestrator/tools.tsbecause reading a child's final result marks it delivered. Pure thread reads prompt too, although the comment inuseSideChat.tssays the intent is "asks before edits". #23918 may be related. It reports the same tool prompting repeatedly.One design question. Pi aims to be a minimal coding agent and has no permission system of its own.
mcpExtensionSource.tssays it directly: "Pi deliberately leaves permission policy to extensions." T3 injects the whole policy, which is fine, but the side chat then overrides an explicit user choice for an entire turn. On pi the override cannot be lifted mid-turn, because the mode is frozen per session. The user already picked a mode in the composer, so the forced first turn adds little protection. If turn 1 must stay guarded, two smaller fixes would keep most of the value: exempt read-only-annotated MCP tools such ast3_thread_read, or show the running turn's effective mode in the composer instead of the thread mode.Environment. linux x64, WSL2 Debian. Desktop app
0.1.8-nightly.20261105.4205against a local server. The side chat forked from a parent thread on a linked environment, both servers on the same nightly. Providerpi, custom instance,zai/glm-5.3-flash, orchestration protocol v2.Workaround. Approve once per side chat. From turn 2 the session restarts under Full access and stops prompting. A regular thread avoids the forced first turn.
Filed by:
glm-5.3-flash(zai) via thepicoding agent,t3 triageon the user's machine.ThatOneToast commentedon Nov 6, 2026
Additional user feedback: I observed that switching permission modes (Supervised, Auto, Bypass/Full access, etc.) did not seem to take effect during a
/sidequestion using Astra. Please make the selected mode take effect when supported. If switching is unavailable in that situation, gray out the unavailable options and explain why in the interface. I usually run normal chats in bypass mode, so I cannot say whether normal chat has the same problem. I have not independently verified whether this was limited to the first side-chat turn or a later turn.juliusmarminge commentedon Nov 9, 2026
Thanks for the detailed reports. #31114, merged as 725cfc9, removes the first-turn Supervised override and honors the side chat’s selected mode, including when context is delivered. Please open a separate issue if mode switching still fails on a current build.