FleetView bg-session dispatcher defaults to Opus 4.7 instead of latest model; ignores ANTHROPIC_MODEL and settings.json `model`

Status Fixed / completed

Reported on v2.1.159

Maintainer reply ✓ Yes — bcherny

Activity 4 comments · opened Jun 1, 2026 · closed Aug 19, 2026

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Summary

When launching claude agents (FleetView), the parent agents-view session correctly boots on the latest model (Opus 4.8, picked up from ~/.claude/settings.json's model field). However, background sessions dispatched from FleetView default to Opus 4.7, regardless of:

ANTHROPIC_MODEL env var set when launching claude agents
The model field in ~/.claude/settings.json
The availableModels list in ~/.claude/settings.json

The only way to make dispatched bg sessions boot on 4.8 is to pass --model claude-opus-4-8[1m] explicitly to claude agents. This means FleetView has two independent model defaults — one for the parent UI (reads settings), one for the dispatcher (hardcoded fallback to 4.7) — and they diverge.

Environment

Claude Code version: 2.1.159
OS: macOS 15.x (Darwin 25.5.0)
Account type: Enterprise
Per the model config docs, Opus 4.8 is the default for Max/Team Premium/Enterprise/API accounts.

Reproduction

Confirm ~/.claude/settings.json contains:

``json { "model": "claude-opus-4-8[1m]", "availableModels": ["claude-opus-4-8[1m]", "claude-opus-4-7[1m]", ...] }``

Run plain claude → boots on Opus 4.8 ✅
Run ANTHROPIC_MODEL=claude-opus-4-8[1m] claude agents → FleetView header shows Opus 4.8, but the /model picker inside the parent view does not list 4.8 (only 4.7 and below).
Dispatch any bg session from FleetView → the new session boots on Opus 4.7[1m], not 4.8.
Inside the bg session, echo $ANTHROPIC_MODEL returns claude-opus-4-7 (not what was set on the parent).
Run claude agents --model claude-opus-4-8[1m] → dispatched bg sessions correctly boot on 4.8. ✅

Expected behavior

claude agents without --model should fall back to the same "latest available model" default that plain claude uses (or at minimum read settings.json's model field or ANTHROPIC_MODEL). The dispatcher's default shouldn't be hardcoded to a previous-generation model.

Actual behavior

Dispatcher default is pinned to Opus 4.7 regardless of config. The /model picker inside FleetView also seems to be missing 4.8 as an option, so users can't even discover it without knowing to pass --model on the CLI.

Workaround

alias claud='claude agents --model claude-opus-4-8[1m]'

Why this matters

Silent downgrade is surprising — config says 4.8, header says 4.8, but bg jobs run on 4.7 with no warning.
For users who do most of their work via FleetView bg dispatch, this means they're unknowingly running every session on an older model.
The /model picker inside FleetView not listing 4.8 compounds the confusion — there's no UI affordance to discover the available models match what's in settings.json.

~ Automated via Claude

View original on GitHub ↗

3 Comments

github-actions[bot] · 4 months ago

Found 3 possible duplicate issues:

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

abhinas90 · 4 months ago

Good catch, @cchadha2. This is a classic enterprise-environment friction point — the install/auth pipeline assumes a permissive dev machine, not a locked-down org environment.

Diagnostic matrix for corp-locked Claude Code installs:

Package lifecycle blocker: If postinstall scripts are failing (ENOEXEC, EACCES), check whether your org's endpoint protection is blocking child process spawns from the npm/pip install path. Try npm install --ignore-scripts then run the postinstall manually to isolate.

Proxy/auth chain: For SSO/proxy issues, dump the full request chain: npm config list, env | grep -i proxy, and check whether NODE_EXTRA_CA_CERTS is set. Claude Code often hits a corporate MITM proxy that injects its own cert — the CLI doesn't always trust the system keychain.

Filesystem policy: If files are being blocked post-install (execution policy, AppLocker, Defender), check ls -la ~/.claude/ for files owned by root when they should be user-owned. A sudo npm install -g can create root-owned config dirs that break subsequent user-level operations.

Network egress: Run curl -v https://api.anthropic.com/v1/messages from the affected machine. If it fails with cert/proxy errors but curl https://google.com works, you have an API-specific proxy rule blocking Anthropic's endpoints.

This is 100% a deployment/ops problem, not a bug. Every enterprise engineering team hits this — there's a clear hardening path once you know which layer is blocking you. Happy to share the full rollout checklist if helpful.

bcherny collaborator · 1 month ago

Fixed in 2.1.161 — changelog: "Fixed background sessions dispatched from claude agents booting on a stale model from the daemon's environment instead of the model in settings.json" (https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md). Closing — reply to reopen if it still happens on the latest version.