accounts.sh can silently contradict the registry — CodeV should self-check what it just generated

[grimmerk]

The inconsistency

accounts.json (the registry) and accounts.sh (the generated shell integration) can disagree, silently and in the direction that matters: the registry says an account shares the anchor's auto-memory, while the generated file has no _codev_memory_settings helper and its launcher lines carry no --settings. Sharing is then off in every new shell, with nothing anywhere saying so — the Sharing panel still shows the checkbox ticked, because the checkbox reads the registry.

How it happens, measured

A packaged CodeV rewrites accounts.sh from its own bundled generator on every launch (syncAppPath in src/main.ts, which returns early unless app.isPackaged). So the last app to launch decides the file's contents. Regenerate from a checkout that has the feature — yarn account regenerate — and then open an older installed CodeV, and the older template silently replaces it.

Observed on this machine on 2026-09-19, a few hours after #160 merged: the installed app was still 1.0.91, it regenerated accounts.sh at launch, and the result contained zero occurrences of the string memory while the registry still had "shareMemoryWithAnchor": true for a non-anchor account. The generated dispatcher branch was back to its pre-#160 form:

work) shift; env CLAUDE_CONFIG_DIR="$HOME/.claude-work" claude "$@" ;;

The same shape applies to any future accounts.sh feature, not just shared memory — a downgrade, a half-finished install, or a build that was never installed all produce it.

Why this belongs in CodeV rather than in a shell check

CodeV is the only party that holds both sides: it owns the registry, it owns the generator, and it is the thing that rewrote the file. It can therefore do what an external checker cannot — fix it — and it already has the UI surface to say so. A check living outside CodeV can only print a line telling you to come back here.

Suggested shape

1. Self-check at launch, right after the regenerate in syncAppPath. Compare the file CodeV just wrote against what generateAccountsSh(registry) produces for the current registry. They are produced by the same pure function, so agreement is the normal case and a mismatch means the file was written by a different build.
2. When they disagree, regenerate and say so. The fix is the regenerate that just ran, so the interesting case is "this file was stale until now" — worth one line in the Accounts tab rather than silence.
3. A signal in the Sharing panel, next to the memory checkbox: the checkbox reflects the registry, so when the generated file does not implement what the registry says, the checkbox is lying. Something as small as a warning dot with "the shell integration on disk is older than this app — reopen your terminal" would close the gap.
4. Cheaper alternative if (1) is too eager: stamp the generated file with the version that produced it (# generated by CodeV <version>) and compare that against app.getVersion(). One string compare, and it also makes the situation diagnosable by eye from the file itself.

Scope note

This is about CodeV's own two-sources-of-truth problem; it is not about Claude Code. A separate hand-run checker covers the Claude-Code-side items (symlinks, hook registrations, settings keys) and deliberately leaves this one out, because printing a line is a strictly worse outcome than CodeV fixing its own file.

🤖 On behalf of @grimmerk — generated with Claude Code