Skip to content

Side chats should inherit the parent thread's permission mode instead of always starting Supervised #29966

New issue
New issue
Closed
Closed
Side chats should inherit the parent thread's permission mode instead of always starting Supervised#29966
Labels
via-triageFiled through npx t3 triage

Description

@joshrad-dev
joshrad-dev
opened on Nov 3, 2026

What happened

I run my main threads on Auto (defaultRuntimeMode: "auto"). When I create a side chat with /side, the side chat is set to Supervised. The main thread often uses the T3 MCP to read the parent thread from the side chat. Those reads hit approval prompts, even though the parent thread is already trusted to run unattended.

Diagnosis

This is intentional, hard-coded behavior in 0.1.6, and it can't be configured:

  • apps/server/src/orchestration-v2/ThreadForkService.ts (around line 114) sets runtimeMode: "approval-required" on every side chat. The comment says "Side chats share the parent's worktree, so they start supervised."
  • apps/server/src/orchestration-v2/ProviderTurnStartService.ts (around line 692) forces approval-required again for the side chat's first turn, and for any turn delivering the parent's context. It does this even if the user picked another mode in the side chat.
  • I found no setting or contract field for side chat permissions in the v0.1.6 source. The saved default mode (defaultRuntimeMode) is ignored for side chats.

The first turn is also the one where the side chat reads the parent thread, so the restriction hits the main use case.

Steps to reproduce

By default, a side chat should inherit the parent thread's runtime mode. A user who runs the parent on Auto or Full access has already accepted that level of trust for that worktree. If the first-turn restriction needs to stay for some cases, make it a setting, and make the restriction visible in the picker. Tool calls that only read the parent thread (t3_thread_read) shouldn't need approval at all.

Steps to reproduce

  1. In the desktop app, set a thread's permission mode to Auto.
  2. Run /side to create a side chat.
  3. Check the side chat's permission picker. It shows Supervised, not Auto.
  4. Ask the side chat something that reads the parent thread through the T3 MCP.
  5. Approval prompts appear.

Version

0.1.6 (stable desktop app).

Environment

Environment - T3 Code desktop app 0.1.6, local server - macOS (darwin arm64, 27.0.0) - Triage CLI 0.1.6 (this is the CLI's version, not the build the bug happened on)

Evidence

I read the source at tag v0.1.6 (commit 2359643cffa6). The two code locations above are the evidence. I did not capture server traces or provider logs for this issue, and I did not reproduce it live in a separate session.

Related issues

Fix applied or workaround

None. The only workaround is approving the first-turn prompts. Per #29010, later turns follow the mode picked in the side chat.

Filed by

Claude Sonnet 5.5 (claude-sonnet-5-5) via Claude Code

Activity

  1. joshrad-dev
    added
    via-triageFiled through npx t3 triage
    on Nov 3, 2026

  2. jjczopek commented on Nov 3, 2026

    @jjczopek
    jjczopek
    on Nov 3, 2026

    Local evidence from a thread database on Linux (WSL2). Build version not recorded.

    • Four side chats (sideChat: true, fork lineage) were created from parents on Auto. Each was stored as approval-required at creation. The model and effort were copied from the parent. The permission mode was not.
    • One side chat was switched to Auto by hand three minutes after creation. Its first run had 8 command approval requests. Its second run, after the switch, had none.
    • A fork without the side-chat flag inherited Auto from its parent.

    This matches the diagnosis above. The manual-switch case did not reproduce here, so #29010 may cover that path.

  3. madebyjulz commented on Nov 3, 2026

    @madebyjulz
    madebyjulz
    on Nov 3, 2026

    Another report from T3 Code Desktop 0.1.7-nightly.20261103.4119 on macOS arm64 (local server, same build), Claude Code.

    I run every thread on Full access. Every side chat opened with /btw or /side starts as Supervised. The local database shows 4 side chats created from 2026-11-02 to 2026-11-03. Each was stored as approval-required, and each parent was full-access.

    This is still hardcoded in three places at cefb544af3, including the client's first-turn runtimeMode: "approval-required" in apps/web/src/components/chat/useSideChat.ts. I'd like side chats to inherit the parent's current mode, first turn included.

    Filed via T3 Code triage by Claude Opus 5.5 (claude-opus-5-5) in Claude Code.

  4. maheshrijal commented on Nov 3, 2026

    @maheshrijal
    maheshrijal
    on Nov 3, 2026

    Another report from T3 Code Desktop 0.1.6, macOS arm64 (darwin 27.2.0), local server, Claude Code and Codex.

    The default permission mode is not overridden (full access). 676 of 681 threads in the local database are full-access. The exceptions are all /btw side chats and their children:

    • Two side chats (one Claude, one Codex) were stored as approval-required at creation. Both parents were full-access.
    • One side chat is now auto. The two delegated tasks it started inherited auto, not the full-access default.

    This matches ThreadForkService.ts:115 and ProviderTurnStartService.ts:692 at v0.1.6.

    Filed by Claude Opus 5.5 (Claude Code) via T3 Code triage.

  5. ondrej-merkun commented on Nov 4, 2026

    @ondrej-merkun
    ondrej-merkun
    on Nov 4, 2026

    +1

  6. makeavish commented on Nov 4, 2026

    @makeavish
    makeavish
    on Nov 4, 2026

    +1

  7. Aguiar012 commented on Nov 4, 2026

    @Aguiar012
    Aguiar012
    on Nov 4, 2026

    Confirmed on 0.1.7 (Windows, packaged build): in that version the override lives in exactly two server-side places, not three.

    1. The side-chat fork plan (ThreadForkService.ts):

    const { delegatedFrom: _delegatedFrom, ...inherited } = input.sourceProjection.thread;
targetThread: {
  ...inherited,
  ...
  ...input.sideChat ? { runtimeMode: "approval-required" } : {},

    Everything else is inherited from the parent; only runtimeMode is replaced with a literal, so a parent in Full access always produces a side chat in Supervised.

    2. The turn-start policy resolution (ProviderTurnStartService):

    thread: projection.thread.lineage.sideChat === true && (sideChatHandoff !== void 0 || !projection.runs.some((previous) => previous.ordinal < run.ordinal)) ? {
  ...projection.thread,
  runtimeMode: "approval-required"
} : projection.thread,

    That is the first-turn / context-delivery supervision from #26901. There is no client-side forcing in 0.1.7 — useSideChat does not send a mode — so sites 1 and 2 are enough to reproduce both "always Supervised" and the #29010 / #28110 behaviour where an explicit Full access selection is silently ignored.

    I verified this by patching both locally: dropping the fork override so the fork inherits the parent's runtimeMode, and making the condition at site 2 never match. Side chats then keep the parent's mode from the first turn on. refuseAboveRuntimeModeCeiling still runs right after the plan, so nothing above the managed-policy ceiling gets through.

    Suggested minimal source change: inherit runtimeMode in the fork with no override, and if the #26901 first-turn supervision needs to stay, apply it as a clamp to the thread's own mode instead of replacing it. That would fix #29966, #29010 and #28110 in one change.

  8. signaldetection commented on Nov 6, 2026

    @signaldetection
    signaldetection
    on Nov 6, 2026

    +1.

    Even with perms defaulting to supervised, if you select to auto before entering prompt will result in requests for approval.

  9. riazus commented on Nov 8, 2026

    @riazus
    riazus
    on Nov 8, 2026

    Also seeing this on T3 Code Desktop 0.1.7 (stable), macOS arm64, Claude Code. The parent thread runs on Full access, and every new side chat starts as Supervised. There's no setting for it: ThreadForkService still has ...input.sideChat ? { runtimeMode: "approval-required" } : {} in this build.

    I'd like side chats to inherit the parent's mode, first turn included, or get a "Side chat default: inherit / supervised" setting.

  10. juliusmarminge commented on Nov 9, 2026

    @juliusmarminge
    juliusmarminge
    on Nov 9, 2026 – with GitCafe Production
    Member

    Thanks for reporting this! #31114 (725cfc9c3d) makes side chats inherit parent permissions, including the first turn. #32315 (e455200077) also carries unsent composer permission changes into new side chats.

  11. juliusmarminge
    closed this as completedon Nov 9, 2026

  12. ristoxy commented on Nov 11, 2026

    @ristoxy
    ristoxy
    on Nov 11, 2026

    Thanks for fixing side-chat permissions in #31114 and #32315. Two related ACP session-option cases remain; these are not a claim that the original side-chat bug is still open.

    Observed with Hermes via acpRegistry on T3 0.1.8:

    1. Delegation to a different model on the same provider. Without explicit target.options, the child loses the parent's _t3/session-mode selection, such as dont_ask. On current main bc3eb6d2, the delegation resolver inherits options only when both provider and model match. Explicitly selecting the same model is not sufficient to reproduce this case.
    2. Restart continuation after a mode change. If the thread's mode changes while a run is active, restarting the server resumes that run with its old selection. In one measured restart, 22 of 23 resumed runs had dont_ask; the exception resumed a run created before the mode change. Current main still takes the continuation's modelSelection from the interrupted run.

    Expected: preserve a compatible agent session-mode option across a model change unless explicitly overridden, and use the thread's current mode for restart continuation. These are agent options, distinct from T3's runtime permission mode fixed here.

    This follow-up is based on the recorded 0.1.8 observations and current source inspection, not a fresh live restart. Would a separate issue be preferable for these remaining cases?

    Written by Hermes Agent (GPT-6.1 Sol), reviewed by a human before posting.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions