[Bug] --remote-control sessions no longer register with FleetView; 404 on /api/claude_code/settings disables fleet gate

Summary

Sessions started with --remote-control (in detached dtach -n mode) no longer register with FleetView or the agents view. They get a ~/.claude/sessions/<pid>.json file but no ~/.claude/session-env/<sessionId>/ marker dir is created, no repowise/MCP child processes are spawned beyond a basic playwright child, and interactive remote-control dialogs pop in the FleetView UI and vanish before they can be responded to, leaving the session stuck.

This used to work reliably for ~6 months and started failing ~2 weeks ago. Client binary mtime confirms no Claude Code self-update in that window (still on 2.1.138, May 10 mtime) — so this looks like a server-side change in the /api/claude_code/settings 404 response handling, or in a gate that previously defaulted permissive.

This is not the same as #53666 — that issue was the cosmetic ENOENT log noise. This is downstream functional behavior caused by the same 404 path.

Symptoms

Two observed manifestations, both reproducible:

1. No FleetView visibility for fresh --remote-control sessions. Sessions spawned with dtach -n claude --remote-control <name> don't appear in FleetView's session list or in claude agents. Pre-existing sessions started weeks ago (still running, never restarted) remain visible.

1. Vanishing dialogs in attached sessions. Sessions that DO appear in FleetView (older ones, or attached dtach -c foreground sessions) pop up an interactive permission/dialog modal that disappears before it can be answered. The session is then stuck — no input gets through, no way to recover except kill.

Repro

# Wrapper script (have used this exact form for months)
dtach -n /tmp/claude.$(date +%s).test.session \
  claude --dangerously-skip-permissions --name test --remote-control test

Then check:

ls -la ~/.claude/sessions/<pid>.json          # exists ✓
ls -d ~/.claude/session-env/<sessionId>/      # MISSING ✗  (should exist)
ps --ppid <pid>                                # only 1 MCP child instead of expected 2-3

Working sessions started before the regression have the session-env/<sessionId>/ marker dir and 2-3 child MCP processes. New sessions have neither.

Evidence: server-side 404 is the trigger

--debug log on every fresh session start shows:

2026-06-26T19:34:41.425Z [DEBUG] Remote settings: No settings found (404)

Direct curl with the same OAuth bearer used by the CLI confirms:

GET https://api.anthropic.com/api/claude_code/settings
HTTP 404
{"type":"error","error":{"type":"not_found_error","message":"Not found.",
 "details":{"error_visibility":"user_facing"}},
 "request_id":"req_011CcSS68J9qGr2fSxa2WL2y"}

Other endpoints work fine on the same token — /api/oauth/account/settings returns 200, Policy limits: Fetched successfully in the same startup, plus all claude.ai MCP proxy connections succeed. So this is specifically the /api/claude_code/settings endpoint returning 404 for this account.

The decompiled handler (in bin/claude.exe) treats 404 as "no settings — use empty object":

if (response.status === 204 || response.status === 404)
  return y(`Remote settings: No settings found (${response.status})`),
         { success: true, settings: {}, checksum: undefined };

Downstream, an empty settings object appears to keep fleetGateRejected true (or isAgentsFleetEnabled false), and the per-session session-env/<sessionId>/ directory creation in the remote-control startup path is skipped. The claude binary contains these strings nearby: isAgentsFleetEnabled, fleetGateRejected, ensureFleetGateHydrated, gb-before-fleet-gate, session-env, .fleetview-heartbeat.

Account context

• Subscription tier: team / default_claude_max_5x
• OAuth scopes include user:sessions:claude_code
• trustedDeviceToken present
• Re-login (/login) refreshes the token cleanly but does NOT fix the 404 — so it's not a stale-token issue, it's an account entitlement or backend record for this account that's missing.

Asks

1. Why does /api/claude_code/settings return 404 for this account when other endpoints return 200 on the same token? Was a remote-settings record removed ~2 weeks ago, or did the response shape/handler change?
2. The 404 → empty settings → FleetView-off chain looks like a regression on the server side — previously it apparently defaulted permissive. Can the empty case default back to fleet-enabled, or can clients on a team plan get a non-empty response?
3. Separately, the vanishing-dialog behavior (symptom 2) sounds like the remote-control output channel breaks when the gate is half-hydrated; that may be worth a separate look even if the gate logic is correct.

Diagnostic data

• Request ID for the 404: req_011CcSS68J9qGr2fSxa2WL2y
• Claude Code version: 2.1.138
• Platform: Ubuntu 22.04 (Linux 5.15.0-179)
• Node: v22.22.2
• Install: npm i -g @anthropic-ai/claude-code (no self-update since May 10 — verified via mtime)
• dtach mode: -n (detached). Foreground dtach -c (attached) still works as a workaround.

Happy to provide additional debug logs, env, or strace if useful.

 ▐▛███▜▌ Claude Code v2.1.138
▝▜█████▛▘ Opus 4.7 (1M context) · Claude Team
 ▘▘▝▝~/hc-portal

────────────────────────── demo_spawn ──
❯ Try "edit TaskMilestoneModal.tsx to..."
────────────────────────────────────────
⏵⏵ bypass permissions on (shift+tab to cycle)

function gWH(){ // isFleetDisabled
  return EH(process.env.CLAUDE_CODE_DISABLE_AGENTS_FLEET) ||
         oI()?.settings.disableBackgroundAgents === true ||
         D01() || B7() || false;
}

function id(){ // isAgentsFleetEnabled
  return !gWH() && J$("tengu_slate_meadow", false);
}