Changelog

What broke

A user's installed CodePulse v2.3.142 stopped surfacing tool calls in Telegram even though the bridge was running, hooks were registered, and /health happily reported hooksTriggered=42. Investigation traced it to the CODEPULSE_HOME user-scope env variable disappearing from HKCU:\Environment during a session. The hook script's resolver chain — env var → registry → script-location inference — failed at all three tiers, so the script silently exited at line 47 with no log entry, no diagnostic, no /health change. From the operator's seat, hooks were "running" while in reality nothing reached the bridge.

Likely causes for the env-var disappearance: setx's 1024-character Path-truncation race clipping other vars, AV / profile-cleaner sweeps, registry pruning, elevation context drift. The whole class is a known Windows fragility surface.

What changed (TAB-649)

• Anchor-file resolver as priority #1. The installer now writes codepulse-home.txt next to the hook script (D:\ClaudeCode\hooks\codepulse-home.txt). The hook reads this file FIRST. Plain UTF-8, no BOM, single line: the absolute path. Self-contained at the install site — no registry, no env var, no inference required.
• 4-tier resolver chain with structured trace: anchor → env → registry → inference. Each failure step is recorded so /health can report exactly which tier(s) failed.
• Self-heal diag flag. When all four resolvers fail, the hook atomically stamps %APPDATA%\CodePulse\diagnostics\hook-unresolved.flag (UTF-8 JSON, atomic tmp+rename write) and exits 0 (never blocking Claude). The bot's /health endpoint reads the flag and surfaces:

  "hooksHealthy": false,
  "hooksReason": "resolver-failed:anchor-missing,env-empty-or-invalid,inference-no-env"
  

  This is what would have caught the original outage 4 hours earlier. Successful hook runs clear the flag (Remove + truncate-to-empty fallback if the file is locked) so /health self-recovers within one Claude tool-call.
• Stale-window logic. Flags older than 5 minutes are treated as recovered (the next successful hook clears them anyway). Future-stamped flags from clock skew also treated as stale (symmetric Math.abs window).
• Test-only registry-bypass env var so the resolver-chain integration test isolates from the host's real HKCU (registry can't be mocked).
• Anchor-write is non-fatal. A transient AV / disk hiccup at anchor-write time logs a WARN but the install still succeeds — the hook will fall back to env / registry / inference if the anchor isn't there.

Two-round adversarial review

Round 1 (diff-scope) found 4 HIGH + 8 MEDIUM + 1 actionable LOW. All applied: install-fail-hard relaxed to WARN, registry-bypass for tests, atomic flag write via tmp+rename, truncate fallback for locked clears, symmetric stale-window for clock skew, treat-unparseable-ts as stale, env-vs-anchor mismatch warn surfacing in hook-events.jsonl, strict-match assertions in tests, orphan-tmp sweep after concurrent writes.

Round 2 (fresh-eyes) found 3 MEDIUMs (all comment/cleanup) + assorted LOWs. All MEDIUMs applied: tightened the readHookHealthFlag JSDoc, corrected the MoveFileEx atomicity claim (it's near-atomic on NTFS, not strictly atomic), added orphaned .tmp.<PID> cleanup sweep.

Tests

21 new tests in tab-649-anchor-resolver.test.ts across 4 sections: place-hooks anchor write semantics, uninstall cleanup, resolver-chain via isolated hook copy (anchor / env / inference / all-fail), and readHookHealthFlag staleness + parse semantics. 250+ adjacent tests pass with zero regressions.

Looking forward

This release was the first of four tracking the same epic — TAB-665 — that hardens the install-time path resolution end-to-end. v2.3.146 follows with installer Step 5 demoted to non-fatal so transient registry hiccups can't roll back working installs. v2.3.147 ports the same architecture to the bash hook for Linux/macOS parity.

What landed

• TAB-645 — RL-active gate on non-delegate hook suppression. TAB-642's blanket suppression (Theme 4) was too aggressive: it muted Code-mode interactive sessions even when no RL was active. Result: Code-mode users lost their Telegram tool-call surface as soon as ANY RL session was registered, regardless of the session firing the hook. Fix: gate the suppression on realLifeActiveResolver?.() !== false so the bridge only suppresses non-delegate hooks when an RL session is actively attached. When RL is detached, Code-mode hooks resume firing normally.
• TAB-646 — Streaming UX cleanup. Two fixes:
  • Placeholder removed. The "thinking..." card flickered on/off because every streaming chunk re-edited it. Dropped the placeholder entirely; first content chunk renders directly.
  • Connector-account marker. RL responses include a hidden marker pointing at the originating Connector account (e.g. [connector:[email protected]]). Marker survives streaming chunk-by-chunk reassembly so the response card footer correctly attributes the source.
• TAB-648 — Calendar pending-RSVP events. mcp__claude_ai_Google_Calendar__list_events was filtering out events the user hadn't yet RSVP'd to. RL system prompt updated to instruct Claude to include pending-RSVP events in calendar listings. New diagnostic logs tool_use args for connector tools (200-char preview) so future tool-arg bugs are debuggable from the bridge log.

v2.3.142 — the version that hit the outage

v2.3.142 was running on the user's machine when the CODEPULSE_HOME env var disappeared from HKCU:\Environment and every Telegram tool-call surface went silently dark. Investigating that outage led to TAB-649 (the anchor-file resolver, shipped in v2.3.145) and the EPIC TAB-665 follow-ups (v2.3.146–v2.3.147). v2.3.142 itself is fine — the env-var-disappearance bug is environmental, not in the bridge — but it's the last release before the resolver chain was hardened.

Tests

Each fix gets a regression test: TAB-645 has a non-delegate stop-hook test that asserts the gate flips correctly; TAB-646 has a streaming-marker preservation test; TAB-648 has a tool-arg diagnostic log assertion.

What landed

• TAB-615 — Voice command suppression in Real-life mode. Voice transcription routes to a Code-mode planner that doesn't understand RL semantics. Until this fix, sending voice in RL mode would queue a phantom Code-mode plan that never fired. Now: voice in RL is detected at the Telegram input layer and routed to the RL workflow directly.
• TAB-644 hook-dedup. Two simultaneous stop-hooks (parallel claudes both finishing within ms of each other) fired two Telegram approval cards for the same logical action. Fix: dedup window per (session, classification, target) for 3s.
• TAB-644 Connector auto-allow. Read-only Connector tools (mcp__claude_ai_* Gmail-list-emails, Calendar-list-events, etc.) were asking for approval on every call. They're read-only and idempotent — no reason to gate them per call. Now auto-allow with toast notification.
• TAB-644 format prompt. RL system prompt updated to emit clean Telegram-formatted responses (correct line breaks, emoji-friendly, no Code-mode markdown that Telegram parses badly).
• TAB-644 answer placement. Response card now appears AFTER the approval cards in the Telegram thread, not before. Reading order is "approval cards → answer", matching the visual flow of how the conversation unfolded.
• TAB-644 allow-toast gate. The "Auto-approved: X" toast now respects per-user mute preferences. Spam-prone for users with high tool-call rates.

Why these matter

After the TAB-626 isolation redesign (v2.3.136–v2.3.138), the RL workflow was structurally sound but the user-facing surface still had rough edges. This release range is the polish pass — small individual changes, big cumulative quality bump for the Telegram experience.

How you'll notice

• Voice in RL: works the way you'd expect (your voice command becomes the RL turn, not a phantom Code plan).
• Reading the thread: less visual noise, fewer duplicate cards, response below the approvals.
• Connector tools: fewer interrupting approval prompts for the read-only ones; the write-side (send-email, create-event) still asks every time.

Tests

Hook dedup gets a multi-PID concurrency regression test. Connector auto-allow gets a per-tool-name read-classifier test. Format-prompt and answer-placement get rendered-output snapshot tests.

What landed

• TAB-626 — Real-life fully isolated from CLI (the redesign). The original Path D plumbing reused the Code-mode CLI bridge with a realLifeMode flag. After two weeks of Phase 6 polish that boundary started leaking — Code-mode hooks bled into RL sessions, Code-mode response chrome appeared in RL Telegram cards. The redesign extracts a dedicated persistent-cli-bridge.ts for RL with its own session registry, prompt template (no Code-mode preamble), and streaming pipeline. Boundary B3 (UI chrome) and B4 (learned patterns) are now structurally enforced, not just convention.
• TAB-640 — Production smoke-test fixes. Three classes of bugs caught in the first wave of real-user RL testing:
  • Mid-spawn race — RL session got registered AFTER its first hook fired, so the bridge briefly treated it as a non-RL Code session. Fixed by registering at spawn intent, not at spawn confirm.
  • Response card frame — first RL response card's frame dropped because the placeholder bubble swallowed the formatting.
  • Placeholder UX — the "thinking..." card position was wrong (above the approval cards instead of below). Fixed alignment.
• TAB-641 — Stop-hook diagnostic instrumentation. Added trace-level logging across the entire stop-hook session-id flow. Caught two bugs that had been lurking since v2.3.130 (the cross-session contamination next bullet) and provided the data needed for TAB-642 + TAB-643.
• TAB-642 + TAB-643 — Cross-session contamination fix. The Code-mode interactive hook would fire mid-RL turn and pollute the RL Telegram chat with Code-mode auto-allow toasts. Fixed via TAB-642's blanket !isDelegate early-return, then refined by TAB-643's instrumentation and (later) TAB-645's RL-active gate.

Why these matter

Real-life mode is now production-ready as an isolated workflow. The Phase 6 architecture (TAB-629–TAB-633) couldn't fully eliminate Code-mode chrome leakage without TAB-626's deeper isolation. Combined with TAB-640–TAB-643's bug-fix sweep, the system is stable enough for early-access RL users.

What this unblocks

The follow-up wave (v2.3.139–v2.3.141) layers voice + UX polish on top of this isolation. Without TAB-626's clean separation, every UX polish would have had to manually re-validate Boundary B3 / B4 invariants — instead, those are now structural, so polish work focuses on the user-facing surface.

Tests

Two adversarial review rounds applied to the TAB-626 redesign. The Phase 8 review (TAB-635) re-validated the entire RL surface end-to-end after redesign. Production smoke-test fixes from TAB-640 each got dedicated regression coverage. Total tests added: ~85.

What landed

• TAB-629 — Stop-pass card suppression. Real-life sessions no longer surface the Code-mode [Reply][Wait Quietly][Stop] chrome. RL is request/response — the user is waiting for an answer, not orchestrating a long-running task — so the stop-pass card was visual noise. Bridge now returns empty 200 on RL stop classification.
• TAB-630 — Routing. Real-life messages route to a dedicated workflow path instead of going through the plan-module's branched code. Cleaner separation, fewer "is this RL or Code?" branches scattered through the orchestrator.
• TAB-631 — Dedicated message handler. New rl-module.ts owns RL message lifecycle: receive → spawn → render. Replaces the four if isRealLifeMode branches in plan-module.ts. Same Boundary B3 / B4 invariants enforced (RL chrome stays in RL, RL approval state stays out of the Code engine's learned patterns).
• TAB-632 — Slim card layouts. New approval-card templates designed for RL: minimal header, action verb + target, single line of metadata. Three variants — response, read approval, write approval. Mirrors the brevity Telegram users expect in conversation, not the full Code-mode chrome.
• TAB-633 — Read/write classifier + per-topic policy. Tool calls classified as read (low-stakes, often auto-approved) vs write (always asks). Approval policy is now scoped per Telegram topic — a heavily-trafficked Gmail topic builds its own learned-pattern set independent of a quieter Calendar topic. Boundary B4 enforced: RL learned patterns never leak into the Code-mode ApprovalEngine's pattern store.
• TAB-635 — Cross-phase safety review. Two adversarial review rounds applied across Phases 1–6, fixing 9 CRITICAL+HIGH findings around the RL-vs-Code session boundary.

What this fixes for users

Real-life mode goes from "works but every interaction has Code-mode UI chrome" to "feels like a clean Telegram chat with a smart assistant." Tap an approval card on Gmail and you see the recipient list and subject preview, not the file-path-and-line-number widget designed for Bash commands.

Tests

Comprehensive RL test coverage added across the new rl-module.ts, the slim-card renderers, the read/write classifier, and the per-topic policy store. Adversarial review × 2 round each on Phases 5–8. Total RL-side coverage now mirrors the Code-mode suite.

The headline change

Until now CodePulse was a code-only assistant: Telegram drove the Claude Code CLI, which drove your repo. v2.3.125–v2.3.130 introduces Real-life mode — Telegram driving Claude Desktop's MCP toolkit for the rest of your work. Send "summarize my unread Gmail" or "what's on my calendar tomorrow?" or "create a Linear issue for this" and Claude Desktop runs the corresponding MCP tools (Gmail, Calendar, Linear, Drive, Slack, etc.) headless under CodePulse's supervision.

What landed across these six releases

• TAB-597 — Path D foundation. The bridge now spawns a separate Claude session in Real-life mode, configured with the user's existing MCP toolkit instead of the code-mode profile. Two parallel session registries (Code vs Real-life) run side-by-side without contamination.
• TAB-609 + TAB-610 — Version wiring + smoke-test escape valve. VERSION constant wired through bootstrap so every diagnostic surface shows the same number. New escape-valve env var lets smoke-tests bypass Telegram polling for fast bridge-only validation.
• TAB-614 + TAB-620 — Wave 1 approval-card UX. Tool-input renderers produce rich approval cards: Gmail show "from / to / subject", Calendar shows event details, Bash shows the command. Production logging now covers every silent-degradation path in the renderer dispatch chain — operators get a [tool-renderers] warn when a malformed MCP server response is gracefully sanitized.
• TAB-622 — /select picker. New Telegram command that shows a 3-button keyboard: [Code] [Real-life] [Exit]. Tap to switch modes mid-conversation. Replaces the older toggle-via-attach state.
• TAB-623 — Real-life auto-attach. When a user sends a message and Real-life mode is active, the bridge transparently attaches the user to the Real-life session (no manual /select needed every time).
• TAB-625 — CLI MCP toolkit honoring. Real-life mode inherits the user's existing CLI MCP server config from mcp-config.json. Whatever Gmail / Calendar / Linear / Drive servers you already had configured in Claude Code — Real-life mode now uses them.

How you interact with it

/select          → keyboard appears: [Code] [Real-life] [Exit]
[tap Real-life]  → "Real-life mode attached. Ask anything."
(send a message) → Claude runs MCP tools, returns answer in Telegram

Real-life mode supports the same tool-approval flow as Code mode, but the cards are scoped to the connector account (e.g., Gmail recipient list, Calendar event title) instead of code paths.

Why this matters

CodePulse becomes your single-pane Telegram interface for everything Claude can do — not just the repo. Roadmap pieces this unblocks: voice-driven RL approvals (TAB-615 / Wave 1.5), edit-via-reply (Wave 2), batch approvals + confidence scores (Wave 3), TTS readback (Wave 4).

What changed

• TAB-596 Phase 3 — Cross-project --continue delegation. Switching /project mid-session no longer drops the prior project's conversation context. The bridge captures the source-session state, ports it across, and resumes via --continue on the destination project. Earlier phases (TAB-596 P1) already pinned the Claude Code CLI version floor at startup so older binaries can't silently corrupt the session-id wire format.
• TAB-605 — Regex-based MCP auto-approve removed. The previous mcp__* glob auto-approve allowed any pattern matching tool name through without per-tool review. Replaced with an explicit per-tool whitelist for the three CodePulse-internal MCP tools that legitimately auto-approve (mcp__codepulse__*). Third-party MCP tools now route through the normal Telegram approval card.
• TAB-606 — Env spawn allowlist. Every place CodePulse spawns a child process (CLI bridge, hook script invocations, helper scripts) now passes an EXPLICIT env-var allowlist instead of {...process.env, ...overrides}. Parent-process env leakage was the silent vector behind several flaky test failures and a small subset of production-bridge hangs that surfaced when CI-set env vars (GITHUB_TOKEN, RUNNER_*) leaked into long-running spawns.

Why these matter

Each one closes a class of "happens rarely, fails confusingly" bugs. None of these were urgent on their own, but they're load-bearing prereqs for Real-life mode (next release range) — which spawns helper subprocesses, switches projects mid-session, and consults MCP toolkits in ways that exercise every one of these paths.

Tests

Unit tests added across the bridge, hook-installer, and project-switcher surfaces. Total +56 tests; pre-existing surfaces unchanged.

What changed (TAB-591)

• New HOOK_IF_FILTERS env var. JSON object mapping tool-event name → permission-rule string. Example: HOOK_IF_FILTERS={"PreToolUse":"Bash(git *)","PermissionDenied":"Edit(*.ts)"}. Empty / unset → no filters (bit-identical settings.json output to the pre-TAB-591 version).
• Tool events only. Filters are honored on PreToolUse, PermissionRequest, and PermissionDenied — the events the CLI evaluates if against. Filters targeting SessionStart, Notification, etc. are dropped at parse time with a startup warning.
• Defence-in-depth validation. Empty / whitespace / non-string values rejected. JSON keys are case-insensitive but case-collision (e.g. {"pretooluse":"A","PreToolUse":"B"}) surfaces a duplicate key warning instead of silent last-wins. Filter strings capped at 256 characters. Object.create(null) filter maps and hasOwnProperty bracket access prevent Object.prototype pollution from leaking into settings.json.
• Five-line startup observability: filteredEvents info-log lists active filters, plus four warn lines for parseError / unknownEvents / nonToolEvents / invalidEntries, plus a "set-but-no-filters-active" warn when HOOK_IF_FILTERS was non-empty but every entry dropped.

The CRITICAL bug caught pre-ship

Turn 1 adversarial review found that the initial implementation placed the if field at the matcher-entry level (sibling of matcher and hooks). The CLI silently accepts misplaced fields as unknown properties and never evaluates them — every filter would have been a runtime no-op while every positive observability signal (config accepted, filteredEvents log, if key visible in settings.json) lied about it being active. The CLI v2.1.85 docs place if INSIDE the inner hook object (sibling of type / command / timeout).

All 16 of the initial tests had passed because they encoded the wrong contract — the classic "tests pass ≠ feature works" trap. Fix landed before commit: moved if into the inner hook object, added negative tests asserting the entry does NOT have its own if key, rewrote the test-file invariants comment block (which had locked in the wrong layout in plain English alongside the assertions).

Turn 2 fresh-eyes review surfaced 1 MEDIUM (the stale comment block above) and 3 LOW findings (.env.example gap, silent-all-dropped blind spot, prototype pollution surface) — all fixed pre-ship. Final state: 0 CRITICAL / HIGH / MEDIUM open, 144 / 144 relevant tests pass, tsc --noEmit clean.

What landed in source (TAB-595)

• Worker version-injection step. The release workflow now patches wrangler.toml's WORKER_VERSION placeholder with the release tag before wrangler deploy. The Cloudflare Worker echoes that value at https://api.codepulse.at/health, so a post-deploy probe can prove the live bundle is the just-deployed one (not a stale cached version).
• 3-attempt post-deploy verify on /health. Parses the JSON response and asserts version === expected. A silent no-op deploy that leaves the previous bundle running would now fail CI loudly instead of being mistaken for success.
• Step-level timeouts on Install NSIS (10), service deps (10), launcher deps (15), worker build (10), and Deploy Cloudflare Worker (10) — bounded individually to surface hangs faster than the new 60-minute job-level ceiling.
• NSIS path probe across Program Files (x86), Program Files, and ProgramData\chocolatey\bin so a choco install that lands in a non-default prefix is detected correctly.
• $LASTEXITCODE = $null guard before each native-command attempt so a stale 0 from a prior step cannot be mistaken for a fresh success signal.

Honest disclosure — none of this ran in v2.3.120

After v2.3.120 published, the production https://api.codepulse.at/health still returned {"status":"ok","timestamp":"…","version":"0.0.0-dev"} — the placeholder. Investigation revealed the root cause:

• versioning.yml triggers release.yml via gh workflow run release.yml (a workflow_dispatch).
• GitHub Actions rule: workflow_dispatch runs the workflow file from the default branch (main), not from the tag.
• main's release.yml was last touched in early March (pre-v2.0.3) and has been frozen since. Every TAB-595 change in this release lives in the dev source tree but never reached the release-execution path.
• The same shadow retroactively applies to TAB-588 (parse-check), TAB-592 (NSIS resilience, v2.3.117), and TAB-594 (install retries, v2.3.118) — none of those workflow improvements have ever exercised in production CI either, by accident of the registries being available during their deploy windows.

Approved fix in flight

Option 2 root-cause migration: one-time sync main ← dev for .github/workflows/, then remove the workflow_dispatch trigger from versioning.yml and rely on on: push: tags (now reliable thanks to the v2.3.117-era RELEASE_PAT workflow-scope rotation in TAB-593). After that, every release's workflow file comes from the tag, which is on dev — drift-proof by construction. A no-code patch (v2.3.122) will prove the new tag-push trigger end-to-end. TAB-595 stays open until that proof.

What changed (TAB-590)

• Transient vs persistent classifier. Reasons matching a curated regex set (network timeouts, rate-limit responses, file-locked errors) classify as transient → retry. Anything else classifies as persistent → no retry, model sees the denial and adapts.
• Never-retry gate for git writes. git commit, git push, git merge, and git rebase always prompt the user regardless of denial reason. Combined with the existing ALWAYS_PROMPT_COMMANDS and DANGEROUS_COMMANDS lists, this prevents the model from looping retries on operations that touch shared state.
• Two retry caps with TTL eviction. Per-tool-use cap (PERMISSION_DENIED_MAX_RETRIES, default 2 — meaning 3 total attempts) plus a session-level secondary cap (PERMISSION_DENIED_SESSION_CAP, default 10) that defends against the unverified scenario where the CLI assigns a fresh tool_use_id for every retry. Both maps are FIFO-evicted at 10 minutes.
• Kill switch. Set PERMISSION_DENIED_RETRY_ENABLED=false to disable the feature entirely while preserving observability (every decision still logs).
• Telegram throttling. A single denial rarely needs notifying; a flurry of identical denials means something is wrong. The retry-decision messages are throttled per (sessionId, reason-hash) so the user sees one summary instead of N duplicates.

Adversarial review

Two pre-ship rounds caught 2 HIGH (session-level cap, Telegram throttle), 5 MEDIUM, 3 LOW. All fixed before commit. 35 unit tests cover classification, never-retry gate, both caps, kill-switch behavior, wire-format correctness, malformed-JSON tolerance, and reason-string truncation at the size limit.