Changelog

Release pipeline hardening (TAB-594)

• Three install steps gained 3× retry with linear backoff (15s / 30s / 45s): bun install for the service, npm ci for the launcher, and npm ci --ignore-scripts for the Cloudflare Worker. All three hit external registries on every release run.
• wrangler deploy gained 2× retry with 30s backoff. Cloudflare API 5xx is rare but real; one extra attempt eliminates the most common transient failure mode without inviting accidental double-deploys (the Worker bundle upload is idempotent, the DO migration is already applied, and the route binding rebinds to the same target each run, so retry is provably safe for this specific topology).
• No code changes outside .github/workflows/release.yml. No application behaviour changed in this release.

Implementation note

The retries are coded as plain for i in 1 2 3 shell loops with explicit success-marker echoes on retry — log readability is the priority, not generic abstraction. A future version may consolidate this with the NSIS retry block from v2.3.117 if a third transient-failure source appears.

Hooks panel sync (TAB-544)

• Configuration panel finally drives the registered hook set. The 7 checkboxes in the Hooks section had been writing to HOOK_EVENTS in .env, but the installer never read them — it unconditionally registered 7 hardcoded hooks regardless of selection. Three of the panel's checkboxes named hooks the service did not register; four hooks the service did register were hidden from the panel. v2.3.117 unifies the two.
• Three new CLI v2.1.x hooks are now wired: StopFailure (v2.1.78) fires a Telegram alert when Claude's API call fails, TaskCreated (v2.1.84) logs subagent activity, PermissionDenied (v2.1.88) returns a safe no-action stub (full auto-retry semantics deferred to v2.1.119).
• Required-hook backstop. PreToolUse and Stop are force-registered even if disabled in the panel — disabling either silently breaks the approval bridge. Both render in the Configuration tab as disabled checkboxes with a gold REQUIRED badge.
• Two adversarial-review rounds caught 5 CRITICAL, 7 HIGH, and 11 MEDIUM findings pre-ship, including a stale HooksPanel.tsx clobbering HOOK_EVENTS, a PermissionDenied stdout gap when the bridge is disabled, the new bridge endpoints bypassing rate-limit + content-length guards, and a silent HOOK_EVENTS="" drop. All resolved before commit.

NSIS install resilience (TAB-592)

• Pre-installed NSIS is now honoured. The windows-latest GitHub runner image ships with NSIS 3.10 pre-installed. The release workflow now checks C:\Program Files (x86)\NSIS\makensis.exe first and skips the choco install entirely when present — eliminating Chocolatey as a release dependency on the happy path.
• 3× retry with exponential backoff when NSIS is genuinely absent (15s / 30s / 45s between attempts) — covers Chocolatey's typical recovery window for transient 503s without extending normal release time.
• makensis /VERSION is logged at the end so a corrupt-binary install fails with a clear message instead of with a misleading "not found" error two steps later in the build.

Security (TAB-581 Phase 2)

• Sanitization now covers all 11 user-input-to-Claude paths — Adversarial review found the v2.3.100 fix covered only 2 of the 11 paths where user-controlled text reaches a Claude or Haiku call. A new src/utils/sanitize.ts module implements 7 Unicode angle-bracket classes (ASCII, fullwidth, CJK, deprecated, heavy, mathematical, single-angle) and is applied at every Haiku/Claude call site — the SDK path (bridge.ts), the TCVF verification pipeline tiers t2/t3/t4 (security gates that decide Bash command approval), proactive modules (guardian, error-watcher, morning-briefing, proactive-module), summarizer, task-planner, analyzer, router, classifier, and both CLI bridges' systemContext.
• End-to-end runtime verification at the Haiku boundary — 32 unit tests cover every character class plus edge cases; 3 runtime smoke tests inject a malicious </user_task><system>…</system> payload, capture the Anthropic SDK mock's messages[0].content, and assert the escape fired end-to-end.

Installer (TAB-582)

• Installer auto-detect accepts settings.json OR settings.local.json — Modern Claude Code CLI writes only the .local variant. All four detection-time sites (NSIS interactive + silent paths, PS + bash fallbacks) were updated to accept either filename. Post-install validation stays intentionally pinned to settings.json — the file register-hooks.ps1 writes to — so a failed hook registration is never silently masked by the presence of the .local file. TAB-424 Claude Desktop discrimination is preserved.

Stop Hook (TAB-577 Phase 2)

• Per-session continuation cap replaces the blanket pass-override — Phase 1's unconditional classification='pass' override had two problems: it downgraded tier-2/tier-3 question classifications to generic status cards, and it re-opened the TAB-540 infinite-loop protection vector. Phase 2 replaces the override with a per-session stopHookActiveChain counter (cap 10) that force-suppresses runaway continuation chains while preserving classifier output for every turn below the cap. A cleanupStale routine evicts orphan counter entries older than 10 minutes.
• Linux/macOS hook brought in line — codepulse-pulse.sh now mirrors the .ps1 hook's flag-forwarding logic. The shell variant was still running TAB-540's early-exit path and never saw the Phase 2 fix until now.

Service Lifecycle + Uninstall (TAB-589)

• Stop was broken by the TAB-586 regression — is_pid_alive spawned powershell Get-Process which takes 17-25s per call on AMSI-scanned machines. The TAB-586 polling loop called it up to 8 times, producing 20-160s stops. Tokio's 10-second timeout always tripped and Force Kill flashed on every normal Stop. Reverted to tasklist /FI (~80ms vs ~20s) and eliminated the polling entirely: POST /shutdown → fixed sleep(2s) → taskkill /F /T /PID unconditionally. Tokio timeout raised 10s → 60s.
• Uninstall was broken since inception — uninstall.exe carries a requireAdministrator UAC manifest, and Command::spawn uses CreateProcess which does NOT trigger UAC elevation, so every click returned ERROR_ELEVATION_REQUIRED (740). The frontend swallowed the error with a misleading /* app is exiting */ comment, so the button visibly did nothing. run_uninstaller now launches via powershell Start-Process -Verb RunAs with a single-quoted path (safe against $ and backtick injection). HelpPanel gains a confirm dialog, an error banner, and a launching-state indicator.
• Top-right and Dashboard buttons sync — serviceError auto-clears on observed stop via a stopErrorMarkerRef flag. A new listen('service-state-changed') listener handles tray-originated state changes in ~10ms. The header button shows "Stopping..." / "Starting..." with pulsing dots during transitions, and Force Kill only appears after the 60-second Rust timeout OR a 50-second frontend watchdog — it no longer flashes in the happy path.

Install Script Parse Bomb, Round 2 (TAB-588 — second hotfix)

• Parse bomb class #2 — UTF-8 em-dash misread as CP1252 closing quote — PS 5.1 reads BOM-less .ps1 files as the CP1252 ANSI codepage. The UTF-8 em-dash — has byte sequence E2 80 94, and 0x94 maps to a curly closing double-quote (") in CP1252, which terminated the string mid-expression. The v2.3.112 hotfix had actually added a new em-dash while fixing the $Script: bomb — a textbook example of an in-repo encoding regression that neither tsc nor unit tests could catch.
• All 10 installer .ps1 files scrubbed + CI AST gate — Em-dashes, en-dashes, arrows, and box-drawing characters were replaced with ASCII equivalents across every install/**/*.ps1 file. A new CI gate in release.yml runs PowerShell's built-in [System.Management.Automation.Language.Parser]::ParseFile plus a BOM/ASCII scan in ~3 seconds before the 10-minute build step — any future encoding or syntax regression is now caught before the installer binary can be produced.
• Write-InstallLog fallback — Added a no-op Write-InstallLog stub to install.ps1 and added logger.ps1 to the preflight required-files list, so a missing logger no longer crashes the installer before it can write any diagnostics.

Install.ps1 Parse Bomb (TAB-588 — first hotfix)

• $Script: inside a double-quoted string was parsed by PS 5.1 as a scope-qualifier prefix expecting a variable name after the :. A space followed instead, which raised a ParserError at script load time — before any install logic could run — and produced exit code 1 with zero log output and no visible error to the user. Every v2.3.111 install failed silently. The fix wraps the bare $Script reference in a $($Script) subexpression to suppress scope-modifier interpretation.
• Mailto encoding regression — build-support-email.ps1 switched from HttpUtility.UrlEncode (which encodes spaces as + and violates RFC 6068) to Uri.EscapeDataString (correct percent-encoding for mailto:). An explorer.exe fallback for Start-Process was also added to handle machines where no default browser is registered for the mailto: scheme.

Installer Performance (TAB-587)

• Dot-source replaces subprocess cascade — Each install phase previously spawned 3-4 separate PowerShell processes via nsExec::ExecToStack, and every spawn incurred a 3-5s cold-start penalty on constrained machines. install.ps1 is now refactored to dot-source all lib scripts (detect-claude.ps1, place-hooks.ps1, register-hooks.ps1, set-codepulse-home.ps1) and call their exported Invoke-*Body functions directly within a single PowerShell process. All NSIS invocations also gained -NoProfile -NoLogo to shed profile-load overhead.
• Live progress streaming via ExecToLog — nsExec::ExecToStack (which suppressed all output until the process exited) is replaced with nsExec::ExecToLog, so NSIS now receives stdout lines as they are emitted and the progress bar no longer freezes for multi-second stretches.
• FirstRunWizard phase labels — FirstRunWizard.tsx gains rotating phase labels and an elapsed-seconds counter during the service-start wait so users can see what's happening instead of staring at a silent spinner.

Shutdown & Stop Reliability (TAB-585, TAB-586)

• grammY shutdown timeout (TAB-585) — sendToAllUsers previously awaited grammY's HTTP call with no timeout, so a network hiccup or rate-limit could block the SIGTERM handler indefinitely and leave the process alive until an external taskkill. Every sendToAllUsers invocation is now wrapped in a Promise.race with a 3-second bound, and a 10-second master hard-exit timer is armed at SIGTERM entry so the process exits regardless of handler completion.
• Stop button deadlock (TAB-586) — kill_process_tree in the Tauri backend used to spawn PowerShell to terminate the service. PowerShell cold-starts take 1-3s on loaded machines, so the Stop button appeared to freeze with the UI stuck in "Stopping…" indefinitely. It now issues a raw TCP graceful-shutdown to the service's management port, then escalates to taskkill.exe /F /T /PID — no PowerShell in the hot path. A burst-poll loop (500ms x 20) drops the Running-to-Stopped display lag from ~11s to ~2s, and a Force Kill button appears after a timeout so the user always has a one-click escape hatch.

QR Pairing UX Polish (TAB-584)

• Fixed 5s sleep replaced with a 250ms poll — receive_token used to sleep a flat 5 seconds before checking whether the Telegram bot had stored the user_id, making fast phones on reliable networks wait 4-9 unnecessary seconds at the critical first-impression moment. A 250ms poll (up to 25 iterations, 6.25s ceiling) now exits the instant user_id is confirmed — typical resolution is under 1 second.
• Telegram reply and structured diagnostics — A "Pairing confirmed — CodePulse is ready" message is dispatched from the same handler once the token is processed, so the "Starting..." button no longer looks frozen. Structured log lines with elapsed-ms were added to receive_token so diagnostics captures the full resolution timeline.

QR Pairing Mobile Compatibility (TAB-583)

• HTML meta-refresh replaces the 302 redirect — Mobile in-app WebViews (iOS Safari in-app, Android Chrome Custom Tabs, Telegram's own browser) silently swallow HTTP 302 redirects to non-HTTP schemes and third-party deep links. The receive_token endpoint now returns a 200 HTML page containing <meta http-equiv="refresh" content="0; url=t.me/BOT?start=SESSION"> plus a visible "Open Telegram" fallback link. Meta-refresh is universally honored, and a server-side page was preferred over JavaScript because some corporate MDM profiles block JS in WebViews.
• Immediate Telegram Welcome reply — The bot now fires a "Welcome — pairing successful" message the moment the token is validated, so users on mobile get in-Telegram confirmation without needing to switch to Telegram Desktop.