[BUG] Inherited permission mode is silently demoted to permissions.defaultMode (agents-view spawns, /fork) — demoting plan to auto makes it more permissive #89911

Update — the diagnosis in this post is superseded; see the comments below. This is not specific to /fork, and it is not a missing flag. Sessions spawned from the agents view are demoted by a deliberate, server-controlled gate (tengu_agentview_inherit_mode_demote, default on) that lands on permissions.defaultMode instead of a safe floor — so plan gets demoted upward to auto. Two-command repro · mechanism and corrected scope. The fork evidence below still stands as one route into the same failure.

I run Claude Code with bypass permissions. Some sessions created with /fork come up in auto mode instead, and nothing says so. The first sign is a tool call being refused mid-task with "Permission for this action was denied by the Claude Code auto mode classifier", which reads like the model declining the work rather than like the session being in a different mode than I set. In my case the refused calls were git commit and git push on a branch I had just explicitly asked for, so the task simply stalled.

What actually predicts it: the parent's recorded flag, not the version

Every background job writes ~/.claude/jobs/<id>/state.json, including the respawnFlags it was launched with and its forkParentSessionId. Joining each fork to its parent's record — 50 forks on this machine going back to 2026-07-28, of which 45 still have a surviving parent record:

There are no exceptions in either direction. A fork inherits whatever mode was recorded for its parent, and where nothing was recorded it comes up in auto — which matches the permissions.defaultMode: auto in my ~/.claude/settings.json. So the fork appears to re-resolve from settings rather than from the parent's live runtime mode.

Why this first looked like a 2.1.246 fork regression

Plain (non-fork) background launches stopped recording a --permission-mode flag at all starting 2026-08-25T18:55:54, and 14 of my plain jobs now have none. Almost every fork I made after that descended from a flagless parent, so all five bad forks landed on 2.1.246 while all the good ones predated it. That correlation is confounded: a 2.1.246 fork of a parent that did have --permission-mode bypassPermissions recorded (2026-08-26T20:25:33) came up in bypassPermissions correctly. The version is not the variable.

The unrecorded-mode half is its own puzzle

Among plain background jobs on 2.1.246, some record the flag and some do not, from what looks like identical state: the 14 flagless ones were created between 12:28 and 19:34, and three later ones from 20:10 onward all recorded --permission-mode bypassPermissions. I have not established what differs — plausibly whether the spawning interactive session was itself started with an explicit CLI flag versus having bypass set at runtime — but if that is it, then a mode set at runtime is invisible to everything downstream that reads respawnFlags.

It is not a settings change

~/.claude/settings.json has not been modified since 2026-08-23 15:48, and forks were still coming up in bypassPermissions on 2026-08-25 with that exact defaultMode: auto in place. Either way I would expect an explicit --dangerously-skip-permissions on the parent to beat a settings default in a child.

What I expected

A forked session should start in the same permission mode as the session it was forked from, whether or not that mode happens to be captured in the parent's spawn flags. If Claude Code ever does need to put a session in a more restrictive mode than asked for, that belongs in the transcript at the moment it happens, saying so plainly, rather than showing up later as a classifier refusal.

Environment

• Claude Code 2.1.246 (and 2.1.245 for the unrecorded-flag half)
• Linux devcontainer, Linux 7.0.12-linuxkit, CLAUDE_CONFIG_DIR=/home/vscode/.claude
• ~/.claude/settings.json contains permissions.defaultMode: auto and skipDangerousModePermissionPrompt: true
• Affected sessions: 8eb7f699-0cf9-48ed-8ea2-3cbbcd46059a, fork ff0da09d-b2cd-4642-a834-ab1bdd8a6a7f

Repro

Start an interactive session in bypass mode, spawn a background session from it that ends up with no --permission-mode in its respawnFlags, then /fork that one: the fork comes up in auto mode. To inspect without waiting for a refusal:

grep -o '"--permission-mode",[^]]*' ~/.claude/jobs/*/state.json

Edited: an earlier version of this report attributed this to a /fork regression in 2.1.246. That was a confounded correlation — see the parent-mode table.