[BUG] Dispatch-spawned Claude Code sessions ignore user's model and permission-mode settings — no way to change from mobile

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/36133
2. https://github.com/anthropics/claude-code/issues/36496
3. https://github.com/anthropics/claude-code/issues/37118

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Found 3 possible duplicate issues: 1. [[BUG] Dispatch ignores bypassPermissionsModeEnabled — always spawns with --permission-mode default #36133](https://github.com/anthropics/claude-code/issues/36133) 2. Scheduled task ignores model setting, always runs Sonnet #36496 3. settings.json model field ignored at startup (v2.1.81) #37118 This issue will be automatically closed as a duplicate in 3 days. If your issue is a duplicate, please close it and 👍 the existing issue instead To prevent auto-closure, add a comment or 👎 this comment 🤖 Generated with Claude Code

👎

I have been banging my head with this problem for the last several days. Claude continues to hallucinate with its suggested workarounds. It has gotten to a point, where I believe Anthropic probably doesn't have any plan to match OpenClaw and NemoClaw feature to feature. I wish I had not gone down Claude CoWork lane to have built multiple workflows which I now have to baby sit in each of their execution run. Had I implemented those in OpenClaw, I would be better off. Still hoping that Anthropic will come through. So will give it another 2 weeks or so for this bug to be fixed.

I'm a Max subscriber who bought a Mac Mini specifically to run Claude as an always-on autonomous agent via Cowork Dispatch. The current behavior where Dispatch-spawned sessions ignore permission settings makes this impossible — every task requires manual phone approval, which defeats the entire purpose of autonomous agent workflows.

My ideal flow: I send one message from my phone → Claude works autonomously for hours/days → consumes the full weekly token allocation → reports back when done. Right now, tasks stop every few minutes waiting for permission clicks.

Could we get either:

1. Dispatch sessions respecting defaultMode from settings.json (the reported bug)
2. An equivalent of --dangerously-skip-permissions or auto mode for Dispatch/Cowork contexts
3. A CLAUDE.md directive that grants blanket tool permissions for a project

This is the #1 blocker for using Claude as a true autonomous agent. Happy to help test any fix.

+1 Two extensions to roll into this issue (or open as separate but linked):

1. Effort level has the exact same gap. Claude Opus 4.7 added the xhigh effort level for long-horizon agentic work. Claude Code reads effortLevel from ~/.claude/settings.json and supports per-session override; Dispatch's spawn APIs don't. Specifically:

• start_code_task schema exposes model with enum [claude-opus-4-7, claude-opus-4-7[1m], claude-sonnet-4-6, claude-haiku-4-5-20251001] — verified to work when passed explicitly.
• start_code_task schema has no effort parameter.
• start_task (Cowork) schema has neither model nor effort. So Cowork background tasks have no programmatic way to override the hardcoded defaults at all.

2. The in-session UI correctly blocks mid-session changes, but there's no path to pick the right config on a new session either. On clicking the "Legacy Model" dropdown in a running Dispatch task, the UI says: "The model can't be changed once a session has started. Start a new session to use a different model." That's accurate as a mid-session constraint — the gap is that task creation itself doesn't expose model or effort controls, so starting a new session doesn't actually help.

Simplest fix paths, in order of decreasing effort:

1. Have the Dispatch spawner read model and effortLevel from ~/.claude/settings.json (parity with Claude Code; no new UI; respects user prefs globally). This also fixes #49273 and #50200 naturally.
2. Add model and effort parameters to both start_task and start_code_task schemas and have orchestrator surfaces (including the desktop Dispatch UI's "new task" flow) expose them.
3. Add a model + effort picker to the "new task" flow in the desktop Dispatch UI directly.

On a Max plan with { "model": "opus", "effortLevel": "high" } in ~/.claude/settings.json, every Dispatch-spawned session is silently downgraded to a legacy model/effort config I can't change after the fact. Workaround today is having my orchestrator spawn tasks programmatically with explicit model: "opus" — which works for start_code_task but has no equivalent for start_task or for tasks created from the UI.

The original issue says that it defaults to Sonnet but my own experience and others' online _seem_ to indicate that it's using Opus 4.7, thus chewing through tokens quickly when Sonnet could do the job at less expense. Not sure how to prove that, though.

Confirmed on Claude 1.8555.2 (a476c3) on Mac. settings.json with permissions.defaultMode: bypassPermissions, the UI toggle, and launchctl setenv CLAUDE_CODE_PERMISSION_MODE bypassPermissions all set correctly after a full restart — Dispatch-spawned sessions still prompt for bash commands in Dispatch (in Cowork on Claude.app).

Still reproducing on a current Desktop build (a few days behind latest; this has been reported for weeks). My user-level ~/.claude/settings.json sets permissions.defaultMode: "auto". When Dispatch spawns a Code session, it does not come up in auto — it lands in a mode that still prompts for ordinary terminal commands. Other creation paths (New Session in the Desktop Code tab, scheduled routines) honor defaultMode.

Concrete repro I just ran: in a Dispatch-spawned session with the mobile Code-tab picker set to Auto, a plain read-only "git -C <dir> status" still triggered a permission prompt — so the running session was not actually in auto/classifier mode despite Auto being selected from mobile. Changing the mode from the mobile picker does not take effect on the running session, and reopening it on desktop shows the mode never matched what I picked.

Net: Dispatch ignores my configured default and cannot be corrected remotely — the exact situation where I rely on it (away from my machine). Please have Dispatch honor user-level defaultMode.

Bug: Claude Dispatch ignores model in ~/.claude/settings.json

I changed the model in ~/.claude/settings.json to a model other than claude-sonnet-4-6, but Claude Dispatch still uses claude-sonnet-4-6.

Repro

1. Edit ~/.claude/settings.json.
2. Set "model" to a different Claude model.
3. Start a new Claude Dispatch conversation.
4. Delete the conversation and clear memory.
5. Start another new conversation.

Expected

Claude Dispatch uses the model selected in ~/.claude/settings.json.

Actual

Claude Dispatch still uses claude-sonnet-4-6.

Impact

The configured model appears to be ignored or overridden, and there is no clear way to force Claude Dispatch to use the selected model.

This is still an issue. Also adding a screenshot of the Dispatch-spawned Code session from my laptop Desktop app, showing the model it's selected (Opus 4.8 1M) and the permissions (Accept Edits). My Desktop local settings are Sonnet 4.6 and Auto permissions.

<img width="825" height="83" alt="Image" src="https://github.com/user-attachments/assets/ca5d531f-41cd-4a46-9067-51b2b36f91e6" />

Same bug, plus a new failure mode: /model in the Dispatch thread silently no-ops but the thread claims it worked.

Desktop app (Windows, bundle 2.1.205), Pro plan. My ~/.claude/settings.json has "model": "claude-sonnet-5". The Dispatch (Répartition) coordinator thread ignores it. Confirmed by asking it directly, it reports "Claude Sonnet 5."

The new part: typing /model opus in the Dispatch input doesn't switch the coordinator. Instead of failing visibly, the thread replies with a confirmation like "Confirmed: this thread is now running on Opus 4.8, for this session only." Re-asking "what model are you?" from a cold turn still returns Sonnet 5. So the /model command is being consumed as ordinary chat text, and the model plausibly-completes a fake confirmation, which makes it look fixed when it isn't.

This is worse than a silent ignore: a user following the workaround from #67078 gets false-positive feedback that the switch succeeded.

I came across a similar issue, Dispatch uses Opus 4.7 with no apparent way to change this, none of the methods are sticky, always falls back to the legacy model for new Dispatch query.

I came across a similar issue, Dispatch uses Opus 4.7 with no apparent way to change this, none of the methods are sticky, always falls back to the legacy model for new Dispatch query.

Solution, model for dispatch is tied to code model selector within claude desktop. tab over to code new chat. Change to desired model. go over to dispatch and hit delete conversation using the 3 dots to change to your new desired model

Adding a fresh mobile reproduction, since this is still open and bites us daily.

Environment: Claude Code in the Android app, remote-controlling a long-running agent session (steps take minutes, so the human is away between them).

What happens: The user selects a specific model (for us, a Fable-tier model) from the mobile picker. Repeatedly — most reliably after a context compaction / session continuation — the session comes back running a different model than the one selected (we see it revert to an Opus-tier model), and the user has to re-select the intended model again. It does not stick across the compaction boundary, and from the phone there is no reliable way to make the choice persist.

This looks like the same root as #13242 (settings.json model preference ignored on startup) and #59516 (model not preserved after /compact, which was closed as a duplicate), but the mobile manifestation is the one described here in #39889: the choice is dropped and cannot be corrected in a way that holds from the mobile client.

Impact: on a phone-driven, multi-hour agent session the revert is silent — the user only notices later that hours ran on the wrong (often more expensive) model. Cost and behaviour both change under them without a signal.

Ask: persist the mobile-selected model across compaction/continuation, and surface the currently active model in the mobile UI so a silent revert is at least visible.