rdmsm4x - reference - claude-code-fleet-baseline-doctor-findings-20260820 - claude - memory-trim - fleet - 20260823-0254

Claude Code fleet baseline & doctor findings — point-in-time report, 2026-08-20

Extracted verbatim from ~/.claude/CLAUDE.md on 2026-08-23 02:54 EDT during a /doctor pass. It was a dated diagnostic report, not operating guidance, and several claims had gone stale: it stated 2.1.237 on five hosts (actual: 2.1.241 on six as of 2026-08-23), "rdmbair15m5 has 22 plugins" (rdmsm4x has 6), and that rdmbair15m5's signing identity exists nowhere — which was corrected on 2026-08-22: rdmsm4x holds the identity and key.

The durable rules from it were kept in CLAUDE.md in condensed form. Full original below.

Claude Code fleet baseline & doctor findings (v1, 08-20-26)

Read this before trusting any host label in this file

This file is generated on ONE host and propagated verbatim to all five Macs. Relative labels ("Local Host", "Report Origin") name the generating host, never the machine you are reading on. Resolve the current host first, always:

scutil --get ComputerName

An earlier fleet copy propagated ### Node: rdmbair13m5 (Local Host) to all five hosts, which reads as a false claim on the other four. Prefer explicit hostnames over relative labels when editing this file.

Install & update channel — `installMethod` is always null here

All five hosts run Claude Code from a Homebrew cask, never npm and never the native installer. Consequences:

installMethod in ~/.claude.json is null on all five. Homebrew has no value in that field. Never read it as a broken install.
The cask name is the release channel; autoUpdatesChannel in settings is unset and is NOT consulted for brew installs. Detect from the resolved binary path: .../Caskroom/<cask>/<version>/claude.
As of 2026-08-20 all five hosts are on claude-code@latest 2.1.237. rdmpw3265m was on the slower claude-code (stable) cask at 2.1.228 earlier that day and was migrated to claude-code@latest during the fleet update run; the stable cask is no longer installed there. If a host ever reads as "behind" again, check WHICH cask it has before concluding drift — a stable-cask host legitimately trails the fast channel by hours to days.
Check currency against the matching cask or you get a false reading both ways: https://formulae.brew.sh/api/cask/claude-code.json · .../claude-code%40latest.json
Verified 2026-08-20: latest 2.1.237, stable 2.1.228. No duplicate installs, no npm leftovers, no ~/.claude/local anywhere on any host.

Settings: which keys are fleet-synced and which are per-host

Fleet-synced baseline, identical on all five and verified 2026-08-20: remoteControlAtStartup: true · crossSessionInbound: "accept" · inputNeededNotifEnabled: true · agentPushNotifEnabled: true · model: "opus[1m]" · verbose: true · askUserQuestionTimeout/dialogExpiry: "60s". These take effect at session start; a running session cannot be enrolled retroactively, so ListAgents will not show peers that started before the keys landed.

Per-host by design, never force-synced by a script: theme · editorMode · enabledPlugins · skillOverrides · hooks · statusLine · worktree · permissions.defaultMode.

`permissions.defaultMode` is `bypassPermissions` fleet-wide, and that is INTENDED

Confirmed by the owner 2026-08-20. Do not "correct" it to auto, plan, or default.

A live Claude Code session writes its own mode back to ~/.claude/settings.json, so this key cannot be managed by an external script while sessions are running. Claude runs on all five hosts continuously, so any scripted change is re-asserted by the local session within minutes — observed repeatedly on 2026-08-20: a fleet-wide set to auto was reverted to bypassPermissions on all five without any sync job involved. Symptoms that mislead:

The value appears to change "by itself" on hosts nobody touched.
A host can flip between two reads seconds apart (rdmsm4x did).
It looks like a rogue agent or a runaway syncer. It is neither — it is the live sessions.

Practical rule: read defaultMode as an observation, never as a setting you own. To change it for real, change it in the running session (or restart the session), not in the file. This is why the fleet policy lists it as per-host-by-design and never force-synced.

Extensions are NOT fleet-wide

Only rdmbair15m5 has plugins (22 enabled), an MCP server (rdworkbench, tools deferred), and a populated ~/.claude/skills (11). The other four hosts have zero plugins. Never assume a plugin fault found on one host exists elsewhere.

Plugin hooks can ship without the exec bit — exit 126

A plugin whose hooks.json invokes a wrapper directly needs that wrapper executable. superpowers shipped hooks/run-hook.cmd mode 644, so every session start failed with exit 126 / Permission denied — silently, for weeks. Only the directly-invoked wrapper needs +x; scripts it launches via exec bash "$SCRIPT_DIR/$NAME" do not.

chmod +x ~/.claude/plugins/cache/<marketplace>/<plugin>/<version>/hooks/run-hook.cmd

A plugin update re-extracts and may drop the bit again. Also note /Users/rich is a symlink to /Users/richh, so a /Users/rich/... path in a hook error is not the bug.

Transcripts are plaintext on disk — treat them as a secrets surface

~/.claude/projects/**/*.jsonl stores every tool call verbatim, including commands that embed credentials. A UDM root password was found in cleartext in a transcript on rdmpw3275m (2026-08-20). Per CLAUDE.md §3 secrets never belong in a command line: read them from ~/.secrets/global.env or Keychain at runtime instead. Rotate anything already captured; the transcript is not retroactively sanitized.

Diagnostics that are cheap and worth re-running

/context — exact live resident-context measurement (disk estimates are approximate).
/mcp, /plugin, /sandbox — runtime state only a live app can see; a static scan cannot tell you an MCP server is failing to connect.
Fleet probe pattern: ssh -o BatchMode=yes <host>.local 'bash -s' < probe.sh — read-only, parallelizable, no file copy needed.

Host-specific facts that live nowhere else (migrated from `~/CLAUDE.md`, 2026-08-20)

rdmbair15m5 — code signing is broken and unrecoverable locally. security find-identity -v -p codesigning returns 0 valid identities (re-verified 2026-08-20). Team ZU2882L4HT (east coast science, llc) and three com.eastcoastscience.RDWorkbench provisioning profiles are cached and valid to Aug 2027, but no certificate or private key exists on disk and none is backed up — no .p12, no App Store Connect .p8. Simulator work is unaffected; device runs, notarization, and App Store submission are blocked until someone signs in through Xcode. Do not assume a build failure here is a code problem.

xcode-select -p can lie. Read the active developer directory as env -u DEVELOPER_DIR xcode-select -p — a DEVELOPER_DIR in the environment silently overrides what plain xcode-select -p prints, which is how the fleet report got the wrong Xcode recorded on 2026-08-15.