fix(onboard): reuse an existing global store instead of stranding history - #26
Merged
Merged
Conversation
…tory Global onboard always targeted the new canonical (XDG) store, so re-running it on a machine that already had a populated global store (e.g. the pre-rename ~/.agent-sentinel-global) silently repointed Claude Code and Codex at a new, EMPTY store: the user's recorded history looked gone, and clients ended up split across two ledgers. Upgrading users hit this on exactly the step the 0.5.0 release notes tell them to run. - `onboard_global_store_dir()` returns the recognized global store that already holds records, and only falls back to the canonical XDG store on a fresh machine. Global onboard uses it and says when it is reusing an existing store. - Warn about the two surfaces onboard does NOT rewrite when they point somewhere else: an OpenCode registration (agentacct never writes OpenCode config) and a hook command running a wrapper from outside ~/.claude/hooks/. Either one silently splits recording between two stores. - Cover the upgrade path that was never tested: 5 onboard tests (reuse a populated legacy store, canonical on fresh, ignore an empty legacy dir, both mismatch warnings) plus a cleanroom UPGRADE=1 mode with INV6.
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
Global
onboardalways targeted the new canonical (XDG) store. Re-running it on a machine that already had a populated global store — e.g. the pre-rename~/.agent-sentinel-global— silently repointed Claude Code and Codex at a new, empty store. The user's recorded history looked gone, and their clients ended up split across two ledgers.Upgrading users hit this on exactly the step the 0.5.0 release notes tell them to run. Found by dogfooding: my own machine ended up with 7258 events in the old store and 1116 in the new one, with OpenCode and the Claude hook still writing to the old one while MCP wrote to the new one.
The fix
onboard_global_store_dir()returns the recognized global store that already holds records, and only falls back to the canonical XDG store on a fresh machine. Global onboard uses it, and prints when it's reusing an existing store.~/.claude/hooks/. Either one silently splits recording between two stores — which reads as "attribution mysteriously got worse".No data migration machinery: reuse-in-place plus a loud warning and a copy-paste recovery command.
Why it slipped through
Every install test — unit and cleanroom — only covered a fresh machine. There was no upgrade scenario anywhere.
UPGRADE=1mode + INV6: the install must adopt the existing ledger.Validation
INSTALL_METHOD=onboard UPGRADE=1: INV1–INV6 all pass. Fresh mode still all pass.