[BUG] 2.1.238 regression: interactive cli-entrypoint sessions persist thinking as signature-only husks (thinking: "")

Likely not the 2.1.238 binary -- server-side experiment assignment. Same-binary bisect + working fix (Windows 11, VS Code extension, claude-fable-5, Max).

Same machine, same model, same entrypoint: claude-vscode, all on the 2.1.237 bundled binary until the last row:

| Session start (UTC) | CLI | Thinking blocks | With text |
|---|---|---|---|
| 2026-08-20 00:35 (prev day) | 2.1.237 | 221 | 221 |
| 2026-08-21 00:05:24 | 2.1.237 | 6 | 6 (last full block 00:05:59) |
| 2026-08-21 00:08:53 | 2.1.237 | 20 | 0 (first empty block 00:08:57) |
| 2026-08-21 00:30:47 | 2.1.238 | 1 | 0 |

The flip happened between 00:05:59 and 00:08:57 with no binary change -- the extension folder for 2.1.238 was written after the first empty session started (the running session kept its 2.1.237 process and persisted version: 2.1.237 for those empty blocks). So the version boundary in the OP looks coincidental with a server-side switch.

~/.claude.json had a fresh clientDataCacheSlots entry with "experimentKey": "claude_code_prairie_fixture_experiment" plus an atis token; the 2.1.238 binary contains the x-cc-atis header attach. This is the mechanism documented in #75607 (new assignment key there).

Fix that worked, on 2.1.238, no rollback:

1. ~/.claude/settings.json: "env": { "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1" }
2. Delete the clientDataCacheSlots key from ~/.claude.json (back it up first)
3. Reload the VS Code window, start a new session

Thinking summaries populated again on the very next session, still on 2.1.238. showThinkingSummaries: true was set throughout; no claudeProcessWrapper.

Inspect command used (PowerShell), per session JSONL: count "type":"thinking","thinking":"" vs "type":"thinking","thinking":"<text>" and read the "version" field on the same lines.

Follow-up: ran the A/B both directions on 2.1.238, fresh session each time. Restoring clientDataCacheSlots (and dropping the env var) -> next new session's thinking blocks empty. Purging it (and re-adding the env var) -> next new session populated. Same binary, same account, minutes apart; three purged sessions populated, one restored session blank, no exceptions.

Caveat (edited): an already-running session flaps on its own regardless of the cache state on disk -- it went blank -> populated -> blank while the slot stayed purged -- so the assignment appears to be held in-process and refreshed on its own schedule. Do not judge the fix from a session that was open when you purged; start a new one.

Follow-up: narrower workaround confirmed working -- surgical purge of the assignment keys instead of CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 (Windows 11, VS Code extension bundled 2.1.238, claude-fable-5, Max).

The env-var workaround from my earlier comments has a heavy cost: it kills the whole feature-flag fetch, which also disables update checks and flag-gated features (cross-session messaging / /list-agents never register). Turns out the blanking assignment is separable from the rest of the flag transport.

Inside each clientDataCacheSlots slot in ~/.claude.json, the assignment is exactly two keys in data:

• experimentKey: "claude_code_prairie_fixture_experiment"
• atis: "v1...." -- an opaque signed token, which appears to be the literal x-cc-atis header payload. It's signed, so the client presumably can't reconstruct it if it's absent.

Method: delete only those two keys from every slot, leave every other flag key intact, and leave the env var UNSET so the fetch stays live. Since a fetch re-populates the slot, run the purge at every session start (Claude Code SessionStart hook):

// ~/.claude/hooks/purge-atis.js  (hook: {"type":"command","command":"node <path>"})
const fs = require("fs"), path = require("path"), os = require("os");
const cfgPath = path.join(os.homedir(), ".claude.json");
try {
  const cfg = JSON.parse(fs.readFileSync(cfgPath, "utf8"));
  const slots = cfg.clientDataCacheSlots;
  if (!slots) process.exit(0);
  let changed = false;
  for (const slot of Object.values(slots)) {
    if (slot?.data && ("experimentKey" in slot.data || "atis" in slot.data)) {
      delete slot.data.experimentKey;
      delete slot.data.atis;
      changed = true;
    }
  }
  if (!changed) process.exit(0);
  const tmp = cfgPath + ".atis-purge-tmp";        // atomic: never truncate live config
  fs.writeFileSync(tmp, JSON.stringify(cfg, null, 2));
  fs.renameSync(tmp, cfgPath);
} catch { process.exit(0); }                      // never block session start

Result (fresh session after removing the env var + installing the hook): thinking blocks populated AND /list-agents present in the slash typeahead -- i.e. the flag fetch is demonstrably live in the same session whose thinking survives. Under the env-var workaround those were mutually exclusive.

Caveats:

1. The purge protects session starts. If the client applies a freshly fetched assignment in-memory mid-session, a long session could still blank partway through -- I haven't observed this yet, but I also can't rule it out. Will report if it shows up.
2. This works because the header payload rides through the on-disk cache between sessions (consistent with the same-binary bisect above: restoring the file blanked the next session). If delivery ever moves in-memory-only, this stops working.

Still holds that the root cause is the server-side experiment, not the binary -- this just shrinks the client-side blast radius from "all flag traffic" to "the one assignment". A real fix (ending the experiment for affected orgs, or honoring showThinkingSummaries over it) is obviously the right ending.