rdmpw3275m changelog — Claude Code 2.1.280 fleet-wide, live sessions restarted, default model = Opus 5.5 1M / medium

[2026-09-22 19:04:19 → 19:53 EDT · rdmpw3275m · claude Opus 5.5 (1M) · session 5739b30e]

Rich, 19:03 EDT: "update the fleet claude version, exit existing running versions if needed and resume them on the new version of claude, set the default model to default opus 5.5 (1M context)/medium which is claude's default suggested model".

Result (verified 19:52:05 EDT)

permissions.defaultMode = bypassPermissions on all six, and it was never written. Channel: claude-code@latest (2.1.280 is its latest; the stable claude-code cask is 2.1.267).

What was done

• syspolicyd wedge on 3 hosts (rdmpw3265m, rdmbair15m5, rdmbair13m5). The 2.1.280 binary, installed at 11:42 and never launched successfully, hung on first exec: the process sat at _dyld_start in AppleSystemPolicy kernel frames, and syspolicyd showed 0% CPU with 0 log lines in 20 min. Apple endpoints answered in 0.1–0.3 s, so network was ruled out. Confirmed on each host before acting, then sudo killall syspolicyd; 2.1.280 then ran in 1–4 s. Recorded on ISSUE-20260831-19.
• Default model. Your /model → Default on this host had removed the top-level model and effortLevel keys; that is the target state. Removed the claude-opus-5 / max pins on 4 hosts (backups kept, all other keys verified identical, defaultMode asserted unchanged).
• Why it kept coming back. com.eastcoastscience.configsync on rdmsm4x (fleet_config_reconcile.zsh, every 30 min) runs the canonical ~/.agent-coordination/canonical/patch_settings.py on every host, and that patch forced model=claude-opus-5 / effortLevel=max. It re-pinned 4 hosts during the 19:19 run: rdmsm4x 19:23:45, rdmbair13m5 19:29:24, rdmbair15m5 19:43:38, rdmpw3265m 19:47:04.
  • Caught by elimination and log timing. The Remote Control bridge was exonerated by a controlled test, and the dormant claude_quota_monitor_resume.py (which carried the same pin) was patched anyway.
  • The canonical patch now removes the two keys (DEC-20260922-02, backup kept), and I verified both directions on synthetic settings. The re-pinned hosts were cleaned again.
  • Per-model effort tiers (modelSettings: max for opus-5, fable-5-1, fable-5, sonnet-5, i.e. only when a session explicitly picks those models) are kept. They implement the tier table in the global CLAUDE.md. Your /model on this host had emptied them, and the reconciler restored them at 19:49:07.
• Live sessions. New tool rdmsm4x:~/dev/fleet/cc-restart (committed 322fac2, pushed to fleet and backup).
  • It reads Claude Code's own ~/.claude/sessions/<pid>.json. It only restarts sessions that are idle, in the foreground, with no child Bash shells and with a shell parent.
  • It exits with SIGTERM (a typed /exit would be appended to any draft and sent), re-types the session's own argv into its parent shell, and verifies same tty, same sid, the new version, and a transcript that grew.
  • 48 restart operations returned ok:
    • canary d5f5ef68
    • 25 in the first rollout, 19:21:40–19:22:40
    • a hub test
    • 21 in a second pass, 19:50:01–19:51:03, so that sessions live during the re-pin start on the default
  • One more test restart (879ddeaa, during the writer catch) left no captured result line; that session restarted cleanly again in pass 2.
  • 26 terminals are now on 2.1.280. Remote Control bridges came back on every session that had one.
• Deferred: rdmbair15m5 2a3bf406 had a pending one-shot CronCreate check-in for TASK-20260922-01 at 22:52 tonight, which a restart would drop. A detached cc_restart.py --not-before 22:53 --min-idle 180 is armed there, logging to ~/.agent-coordination/cc-restart/logs/deferred-2a3bf406.log.
• This session was already on 2.1.280 and on Opus 5.5 (your /model), so it was not restarted.

Not achieved, and why

• jdmbair13m5 is still on 2.1.278 (ISSUE-20260922-11). Every brew upgrade --cask hangs forever in Homebrew's forked child (notify_register_tz → bootstrap_look_up3 → mach_msg).
  • The host updater had been stuck 2h15m holding brew's lock; it was killed. Nothing had been installed.
  • Ruled out: notifyd; syspolicyd; a plain fork+tzset (fine in 0.11 s). The TZ retry was invalid because bin/brew strips TZ.
  • Its 5 sessions were deliberately not restarted: on 2.1.278 the default resolves to claude-opus-5[1m], so a restart would not deliver the new version or the new model.
  • A reboot would very likely clear it. That is someone's laptop, and it wasn't done unasked.

Records

• Tickets: ISSUE-20260831-19 (comment), ISSUE-20260922-11, ISSUE-20260922-12 (root cause found), DEC-20260922-02.
• Skill: fleet-operations/references/claude-code-install.md on the hub gained this procedure.
• Memory: claude-code-fleet-upgrade-session-restart.
• Fleet bus: 20260922-195255-DE42C029.

How to undo

• Settings: each host has ~/.claude/settings.json.bak-20260922-*-pre-default-model.
• Canonical patch: patch_settings.py.bak-20260922-194751-pre-default-model on the hub.
• Quota monitor: claude_quota_monitor_resume.py.bak-20260922-193301-pre-default-model on the hub.
• Code: git -C rdmsm4x:~/dev/fleet revert 322fac2.