Installer replaces the whole SessionStart array in ~/.claude/settings.json, silently deleting unrelated hooks

[jennifertq]

Version: 0.9.0 · Platform: Windows 11 (x64) · Install channel: install.ps1

What happened

codebase-memory-mcp install does not merge into Claude Code's settings.json hook configuration. For SessionStart it replaces the entire array, deleting any pre-existing entry that belongs to another tool.

Before install, my settings.json had one SessionStart hook (matcher compact) belonging to an unrelated local tool. After install, SessionStart contained only the four cbm-session-reminder entries. The third-party hook was gone.

PreToolUse and PostToolUse were handled correctly — cbm's entries were appended and my existing ones survived. Only SessionStart is destructive.

Reproduction (2/2 attempts)

1. Add any hook under SessionStart in ~/.claude/settings.json
2. Run codebase-memory-mcp install -y
3. Inspect SessionStart — only cbm entries remain

Why this matters

The loss is silent. Nothing in the install output mentions replacing existing configuration, and --dry-run reports hooks: SessionStart (MCP usage reminder ...) without warning that existing entries will be dropped. A user only finds out when the deleted hook fails to fire, which for a compact-matcher hook can be days later. I caught it only because I had taken a backup first.

Related but distinct: #570 covers hooks being written to two representations in Codex. This is about Claude Code's settings.json losing third-party entries.

Suggested fix

Append to the SessionStart array as is already done for PreToolUse/PostToolUse, and use the same ownership markers already present in the Codex config (# >>> codebase-memory-mcp ... <<<) so uninstall can remove only its own entries.

[github-actions]

Thanks for raising this! It looks like a duplicate of an existing issue — the canonical one is linked above. Continuing the discussion there keeps everything in one place. We leave this open for visibility; a maintainer will close it once it's fully covered.

[DeusData]

Thanks for the report. This issue is an exact duplicate of #1200: the title, environment, reproduction, observed configuration loss, and proposed fix are identical. I am closing this copy so investigation and updates stay on the earlier canonical issue #1200.