Changelog — Releases

The headline change

v2.3.172 added /agents templates so you could discover which custom Claude Code subagents are installed on your machine. v2.3.176 closes the loop: typing the agent's name as the first word of /agents start now dispatches the background session as that subagent.

/agents templates                                       → lists installed subagents
/agents start adversarial-reviewer audit the auth flow  → 🟢 Dispatched: cafe1234
                                                          Agent: adversarial-reviewer

Same Telegram surface, same /agents peek / /agents log / /agents stop lifecycle — the session is just running under a named subagent persona instead of as a generic background invocation.

What landed in v2.3.176

• /agents start [<agent-name>] <prompt> — if the first whitespace-separated token matches a name found by the same discoverAgents() walk that powers /agents templates, it is peeled off and passed to the bridge as claude --bg --agent <name> -- "<prompt>". Unknown leading tokens fall through to plain dispatch — exact v2.3.170 behaviour preserved, no breaking change.
• Bare agent name rejection — /agents start reviewer (a known agent name with no prompt) used to silently dispatch a Claude session whose literal prompt was the string "reviewer". v2.3.176 catches this and replies with Prompt required for agent reviewer. Usage: /agents start reviewer <prompt> instead.
• Chat-context early-exit — /agents start now bails immediately on ctx.chat?.id === undefined, matching the guard /agents pin and /agents refresh already had. Prevents spurious background dispatches from channel posts and business messages where there's no addressable Telegram surface.
• Refined /help and /agents usage text — both surfaces now agree on the pin vs refresh empty-fleet distinction (refresh always rotates the message id, pin skips when no active agents), and document the new [<agent-name>] syntax.

How it feels

/agents templates             → lists every installed subagent with scope + summary
/agents start adversarial-reviewer audit the new auth flow
                              → 🟢 Dispatched: cafe1234
                                Agent: adversarial-reviewer
                                Prompt: audit the new auth flow

/agents start review the latest commit
                              → 🟢 Dispatched: feed5678
                                (no Agent line — plain dispatch, since "review" is not a known subagent)

/agents start reviewer        → Prompt required for agent reviewer.
                                Usage: /agents start reviewer <prompt>

The agent prefix resolution uses the same project-cwd that /agents templates uses: the active project root in multi-project forum topics, the global CLAUDE_WORKING_DIR in single-project mode. Project-scope agents (.claude/agents/ walking up from cwd) and user-scope agents ($CLAUDE_CONFIG_DIR/agents/ or ~/.claude/agents/) are both matchable.

Under the hood

AgentsCommands.start() was restructured so the cheap local-FS work happens first and the expensive bridge subprocess happens last. The order is now: empty-input guard → cwd resolve → discoverAgents() (local FS walk) → agent-name peel or bare-name reject → < 4 char prompt guard → cliCompatible CLI version check → dispatch. That ordering means a too-short prompt or a bare-agent-name typo short-circuits before spawning a claude subprocess just to surface an error.

The change went through three rounds of adversarial review. Round 1 surfaced four medium-severity issues (the bare-name silent dispatch, divergent help text, a missing multi-project-DM caveat, and a duplicate cwd fallback); round 2 caught the missing chat-context guard and two low-severity items; round 3 was clean. Eight new tests in agents-commands.test.ts lock in each behaviour (the bare-name rejection, the back-compat fall-through, the agent-name escape under HTML injection, the chat-context bail, the case-sensitivity contract, and the cliCompatible ordering). Full suite: 3513 passed, 1 skipped.

Why this matters

The Claude Code subagent system is what lets you compose specialised, scoped helpers — adversarial-reviewer, release-documenter, frontend-dev-expert, your own — without polluting the parent session's context. Until v2.3.176, you could see those subagents from Telegram (/agents templates) but couldn't actually launch one without bouncing out to a terminal. Now the full loop — discover, dispatch, observe, complete — lives in chat.

The release was itself the first end-to-end test of the new feature: /agents start release-documenter ... was the command that produced this entry in docs/RELEASES.md. Auto-shipped by the release pipeline; existing installs receive the update on their next poll.

The headline change

Two bugs that v2.3.171 through v2.3.174 tried to fix four times across four releases are finally dead. The pin bug — /agents pin replied "Pin restored" but no banner appeared — and the Windows console popup that flashed for ~150 ms on every service cold start (most visibly on every auto-update install). Both root causes were traced after research-first investigation, not by patching symptoms.

What landed in v2.3.175

• /agents pin and /agents refresh rotate the pinned message id — previously they re-pinned the cached message_id, but Telegram clients track per-message_id dismissal state when a user clicks the × on the pinned bar. The re-pin returned ok: true and getChat reported the id as pinned, but the client filtered the visible UI because no new "Pinned X" service message fired. Rotation (clear the old + send + pin a brand-new message with a new message_id) generates a fresh service message that bypasses the dismissed-set deterministically.
• /agents refresh always rotates, even on empty fleet — semantic: "update the pin content to reflect current state." A 5-minute-old "3 working" pin should NOT survive a refresh that found no agents.
• /agents pin skips when no active agents — semantic: "make my banner visible NOW." No banner is pinned for an empty fleet; you get a friendly note instead.
• Cold-start Windows console popup eliminated via VBS launcher — Tauri launcher now spawns wscript.exe //B codepulse-service-hidden.vbs which calls WshShell.Run with intWindowStyle = 0 (SW_HIDE). The launcher chain is now hermetic: no link can produce a visible window at any point.
• 5-second per-(chat, user) rotation throttle — prevents Telegram 429 exhaustion if the user spams /agents pin repeatedly. Invisible to genuine use; bounds the API cost at 3 calls per 5 s per user per chat.

Under the hood

The pin root cause is documented in the Bot API: pinChatMessage is defined as "add a message to the list of pinned messages" — idempotent when the same id is already pinned, no new "Pinned X" service message emitted. Telegram clients use the service message as the cue to render the pinned bar; without it, a dismissed bar stays dismissed forever for that id. There is no Bot API webhook for pin/dismiss events, so the bot cannot detect the dismissal directly. The only workable fix is rotation.

The popup root cause is upstream Bun bugs #19916 + #24164, both open and unfixed: bun build --compile produces a CONSOLE-subsystem .exe that allocates a Windows console for ~150 ms on cold start regardless of any spawn-side CREATE_NO_WINDOW flag. The --windows-hide-console build flag that would flip the PE subsystem to GUI is broken on Bun 1.2.14+. The only Windows mechanism that fully suppresses console allocation for a CONSOLE-subsystem child is invocation via ShellExecute with STARTUPINFO.wShowWindow = SW_HIDE, exposed in user space as WshShell.Run.

The release went through 3 rounds of adversarial review. Round 1 surfaced 1 HIGH + 3 MED. Round 2 surfaced 3 NEW HIGH after round 1 fixes (a force-flag race against concurrent bridge events, a poll-loop intolerance to transient parse errors, and a restart-deadlock false-positive). Round 3 was clean. Full test suite: 3500 passed, 1 skipped, 0 failed.

Why this matters

Both bugs were known regressions that survived multiple release attempts because the symptom was easy to mistake for the cause. The pin bug looked like a Telegram API silent-failure (it wasn't — the API was correct, the client was filtering). The popup bug looked like a Bun.spawn configuration issue (it wasn't — it's a PE-subsystem bug in bun build --compile). The fix in both cases required reading the upstream documentation and source-code carefully rather than patching what looked similar. v2.3.175's post-mortems capture the full investigation arc for both bugs, including the four failed attempts that preceded the fix.

The auto-updater swaps in the new installer on the next poll; the next service restart uses the VBS launcher and no popup appears.

The headline change

A narrower hardening pass on the /agents pin reliability path. v2.3.173's getChat ground-truth probe read only message_id and treated Telegram's InaccessibleMessage ghost (an orphan reference left behind after the underlying message has been deleted) as a valid pin. v2.3.174 detects the ghost via the date === 0 sentinel and triggers fresh-message recovery instead of fast-pathing through "already pinned."

What landed in v2.3.174

• probeChatPinnedId() now returns { id, accessible } — accessible = (typeof date === 'number' && date > 0). The date === 0 sentinel identifies an InaccessibleMessage per the Bot API docs.
• PRE-check ghost branch in forcePin — detects cached.messageId === probeActual.id with accessible: false, runs best-effort unpinChatMessage to clear the server-side orphan, wipes the cache, returns the existing 'stale-cache' outcome so the caller's recovery path sends and pins a fresh message that WILL display.
• POST-check ghost branch — defence-in-depth detection after pinChatMessage success, wipes cache and returns 'stale-cache'. Does NOT call unpinChatMessage (the post-check cleanup would race with concurrent pin writers — caught in adversarial review).

Under the hood

Telegram's getChat.pinned_message field is typed as MaybeInaccessibleMessage — a union of Message | InaccessibleMessage. When the underlying message has been deleted from the chat (by user or auto-deletion), Telegram retains the orphan reference and returns the ghost variant. v2.3.173 trusted any non-null pinned_message.message_id match as "still pinned," which the ghost variant satisfies trivially.

Topic-level pins (forum supergroups, topicId !== 0) still skip both probes because getChat does not surface topic-level pinned messages in the Bot API. Documented as a known limitation.

Why this didn't fix the user-reported symptom

The bug as the user experienced it was NOT a ghost pin — the message had not been deleted. The actual root cause (identified in v2.3.175 after exhaustive personal read of the Bot API docs) was per-message_id client-side dismissal state: the user had clicked the × on the pinned bar, and Telegram tracks that dismissal per-message_id, client-side. The bot's re-pin call returns ok: true and getChat returns the cached id as pinned (still server-side present, still server-side pinned), but the client filters the re-pin from the visible UI. Neither v2.3.173 nor v2.3.174 could detect this because there is no Bot API surface for client-side dismissal state.

v2.3.175 fixed it by rotating to a new message_id on every user-initiated pin command. The stale-cache + ghost-pin detection added in v2.3.173/174 remains correct and is still triggered in the small fraction of cases where the genuine server-side conditions hold.

Why this matters

A real but narrower fix. Users with deleted-pinned-message scenarios (a small subset of the broader complaint) saw the symptom resolve after installing v2.3.174. Users with dismissed-bar scenarios continued to see "Pin restored" with no banner until v2.3.175 superseded the entire approach. Documenting both releases honestly because the path between v2.3.173 → v2.3.175 illustrates the difference between fixing a symptom and finding the root cause.

The headline change

A defence-in-depth check around /agents pin after multiple user reports that "Pin restored" wasn't actually pinning anything visible. v2.3.173 stops trusting the Telegram API's success response as ground truth and verifies the post-state via getChat. The fix is correct for the case it targeted — but the user-reported symptom was a different bug class entirely, addressed two releases later.

What landed in v2.3.173

• PRE-check getChat probe in PinStatusManager.forcePin — before calling pinChatMessage, query getChat. If chat.pinned_message.message_id already matches the cached id, return 'repinned' immediately. Saves an API call and short-circuits the false-success class.
• POST-check getChat probe — after pinChatMessage returns ok: true, query getChat again. If the pinned_message no longer matches the cached id, Telegram lied — drop the cache + DB row + return the new 'stale-cache' outcome.
• New recoverStalePin() caller path — /agents pin and /agents refresh handle the 'stale-cache' outcome by fetching a fresh snapshot and sending + pinning a new status message.
• recoverStalePin gated on cliCompatible — adversarial-review HIGH-1 fix; without this, an incompatible CLI would silently pin a malformed status.

Under the hood

Topic-level pins (forum supergroups, topicId !== 0) keep the v2.3.170 behaviour — getChat does not surface topic-level pinned messages, so the probe is skipped and pinChatMessage's success response is trusted. No regression for topic-level operators.

The adversarial review surfaced three MEDIUM concerns: empty-fleet recovery emits a friendly note instead of pinning a "No active agents" placeholder; the suggested throttle preservation was explicitly reverted because it would re-introduce a 4-second delay between the "Pin restored" reply and the actual send (the exact UX bug v2.3.173 was meant to fix); test useFakeTimers wrapped in try / finally for cross-file cleanup.

Why this didn't fix the user-reported symptom

v2.3.173's hypothesis was that the cached message had been deleted on the server side. The user had not deleted the message. getChat continued returning the cached id as pinned — yet the user's client did not show a banner. v2.3.174 narrowed the hypothesis to InaccessibleMessage ghosts (orphan references for deleted messages); v2.3.175 finally traced the actual cause to per-message_id client-side dismissal state via exhaustive personal read of the Bot API docs.

The stale-cache recovery path added in v2.3.173 remains correct and is still triggered in the small fraction of cases where a genuine server-side delete occurs. The infrastructure is load-bearing even though it didn't address the bug it was written to fix.

Why this matters

A real fix for a real (if narrower) case, plus an honest record of an investigation that mistook the symptom for the cause. The path from v2.3.173 → v2.3.175 is documented in the post-mortem for anyone tracing why a four-release fix arc was necessary.

The headline change

Custom Claude Code subagents — .md files with frontmatter at .claude/agents/ or ~/.claude/agents/ — are the unit of composition for specialised, scoped helpers (adversarial-reviewer, release-documenter, frontend-dev-expert, your own). Until v2.3.172 you could install them but had to bounce to a terminal to see which ones existed on the box. The new /agents templates subcommand surfaces them in Telegram with scope icons, descriptions, and the project / user precedence the Claude Code CLI itself uses.

What landed in v2.3.172

• /agents templates (alias /agents list-templates) — lists every reachable subagent for the active project context. Each entry shows scope icon (📁 project / 🏠 user), name, and the frontmatter description.
• discoverAgents(cwd) discovery module — pure async function. Walks UP from cwd for project agents (32-level bound, first ancestor wins, matches Claude Code's "first .claude/agents/ encountered" semantics from the official docs). Honors $CLAUDE_CONFIG_DIR per the env vars docs. Project entries override user entries with the same name.
• Line-based frontmatter parser — Claude Code accepts plain key: value pairs where the value can contain unquoted colons, angle brackets, and escaped newlines. A strict YAML library crashes on this. The parser handles every pattern Claude Code itself accepts.
• Shared resolveDispatchCwd() helper — extracted from /agents start so templates and start both resolve the active project directory the same way (topic project dir in multi-project mode / CLAUDE_WORKING_DIR in single-project / undefined in DM).
• Telegram payload truncation — adversarial-review fix: inline body capped at 3500 characters (Telegram's per-message budget is 4096) with "N more not shown" suffix when the fleet is large.

How it feels

/agents templates
→ 📁 Project (in /repo):
    • adversarial-reviewer — Hostile adversarial code reviewer
    • release-documenter — Generates detailed release documentation
  🏠 User (in ~/.claude/agents):
    • frontend-dev-expert — Frontend React / Vue / CSS / accessibility
    • general-purpose — Catch-all multi-step research agent

  (4 of 4 shown)

The project / user split mirrors Claude Code's own precedence rules. A project-scope agent with the same name as a user-scope agent wins (just like .gitignore-style overrides).

Under the hood

Every file failure is non-fatal (logger.warn + skip), the walk loop is bounded at 32 levels, non-.md files are ignored, and missing directories return []. The defensive posture is deliberate — a single broken agent definition shouldn't take down /agents templates for everyone else on the box.

30 new tests: 22 in agents-templates.test.ts covering walk-up bound, scope precedence, frontmatter edge cases (the <example>\nContext: literal text in frontend-dev-expert.md that crashes strict YAML), missing / malformed files, $CLAUDE_CONFIG_DIR honored; 8 in agents-commands.test.ts covering empty / populated / error / truncation / scope-icon rendering. Full suite: 3477 passed, 1 skipped.

Why this matters

This is half of the TAB-760 arc. The other half — /agents start <agent-name> <prompt> to actually dispatch a session as one of these subagents — ships in v2.3.176. Together they close the loop: discover → dispatch → observe → complete, all from Telegram, with no terminal in the loop.

The headline change

A surgical two-line hotfix for the Windows console flash that was visible whenever the CodePulse service connected. The flash came from two startup probes — claude --version and powershell.exe -Command "echo ok" — both running via Node's child_process.execFileSync, both inheriting Node's default windowsHide: false, both rendering a black console window unless the spawning code opts in to the hide flag.

What landed in v2.3.171

• windowsHide: true on both execFileSync probes in warmDependencyCache() — the only startup-time child_process sites in the service. Two edits in one file.
• No new dependencies, no API surface change — pure behavior fix.

Under the hood

Node's child_process API is independent of Bun's Bun.spawn API. v2.3.169 added windowsHide: true to every Bun.spawn(...) call site across the codebase but execSync / execFileSync use Node's API and inherit Node's default. The crash-context probes (started by src/index.ts:167 at every service boot) were the only places where this mattered for cold-start UX.

What this fix did NOT resolve

The cold-start console-popup that persisted beyond v2.3.171 was a different root cause entirely: bun build --compile on Bun 1.2.14+ produces a CONSOLE-subsystem .exe that allocates a Windows console for ~150 ms regardless of any spawn-side flag. This is upstream Bun bug #19916 (open, unfixed). v2.3.172, v2.3.173, and v2.3.174 each shipped without addressing it because the diagnosis kept circling back to spawn-side flags. v2.3.175 finally fixed it via a wscript.exe VBS launcher that calls WshShell.Run with SW_HIDE — the only Windows mechanism that fully suppresses console allocation for a CONSOLE-subsystem child.

Phase B (deferred)

Six remaining execSync / execFileSync sites across health-checker, desktop-config-importer, guardian, and log-collector are tracked in TAB-761 Phase B. They are user-command-triggered (not startup), so the visible-flash impact is much smaller; deferred to keep the v2.3.171 hotfix small and verifiable per Rule 10 (test before mass change). A vitest static-scan test that fails CI for any future spawn site without windowsHide: true is also tracked in Phase B.

Why this matters

The reported popup at "connect CodePulse" is gone. The cold-start popup at every auto-update install is NOT — that one had to wait three more releases until v2.3.175 traced it to the Bun upstream bug and routed the spawn through a VBS launcher. Documenting both fix attempts honestly because the difference matters: this release ships a real fix for a real (if narrower) class of popup; the broader popup needed an architectural change documented in v2.3.175's post-mortem.

The headline change

Until v2.3.169 you could see your Claude Code background sessions from Telegram — list them, peek at one, fetch logs, stop with a two-step confirm — but you could not dispatch one without bouncing out to a terminal. And if you accidentally unpinned the pinned status bar at the top of the chat, fixing it required forcing activity from a shell. v2.3.170 closes both gaps in a single release.

This is the surface upgrade for the Claude Code agents from Telegram capability that landed in v2.3.165.

What landed in v2.3.170

• /agents start <prompt> (aliases dispatch, run) — type a prompt anywhere you have Telegram. The bridge spawns a fresh claude --bg session and replies with the new session id plus quick-tap commands to peek, log, or stop. Honors the topic project root in multi-project forum supergroups; in single-project mode the cwd is pinned to CLAUDE_WORKING_DIR so a Windows-service install never accidentally dispatches sessions into the install dir.
• /agents pin (alias repin) — re-pin the existing cached status message without fetching a fresh snapshot or sending any new message. Cheapest possible "fix my pin" recovery for the case where you manually unpinned the bar.
• /agents refresh now force-repins after every update — and reports the outcome to you ("Pin restored." / "Re-pin failed — check can_pin_messages permission."). Covers the user-unpinned-then-nothing-changed scenario where the normal edit + auto-re-pin path would dedup-skip.
• /help lists every /agents subcommand — a new "Agents (Claude Code fleet)" section under the existing Session block. The full 10-command set (list, working, blocked, completed, peek, log, stop, refresh, pin, start) is now discoverable without reading release notes.

How it feels

/agents                       → 🟢 2 running · 🟡 1 needs input · ✅ 3 done
/agents start audit auth      → 🟢 Dispatched: a1f3c2d4 (live updates follow)
/agents peek a1f3c2d4         → state, summary, the question it is waiting on
/agents pin                   → 📌 Pin restored.
/agents stop a1f3c2d4         → Yes / Cancel two-step confirm

The pinned status bar updates live (throttled, deduped) as workers progress. Every successful edit triggers a silent pinChatMessage call with disable_notification: true so the pin self-heals if you ever manually unpin it.

Under the hood

PinStatusManager.forcePin() is the new public entry point. It drains any pending throttled update and awaits any in-flight serialized chain before reading the cache, then runs the pin call inside the same per-key serializer that protects every other write. Without this drain, forcePin would race the normal update() send-and-pin path and could falsely return "no message" against a not-yet-populated cache — caught by an adversarial review pass before ship.

A pre-flight CLI-compatibility check on /agents start surfaces the same friendly "update claude" message that /agents list and /agents peek already show, rather than a raw spawn ENOENT. The full 26 new unit tests cover both layers; the existing 3420 keep passing.

Why this matters

The original v2.3.165 release made the Claude Code fleet visible from Telegram. v2.3.170 makes it drivable. You can spawn a session from a kitchen, watch its state change at the bus stop, answer its question in the elevator, and inspect the resulting PR at your desk — all in the same chat thread, with the same pinned bar at the top showing the rest of the fleet. No terminal, no SSH, no app-switching.

The full walkthrough with diagrams lives in the Claude Code agents from Telegram blog post. The release pipeline auto-shipped the signed installer; existing installs receive the update on the next poll.

The headline change

Until v2.3.147, the most an AI could do with your inbox from Telegram was save a draft. v2.3.148 through v2.3.151 close that gap. Type "email John I'll be 5 min late" in your CodePulse chat, tap Send on the preview card, and the email leaves your Gmail Sent folder. Real send, one approval per message, encrypted refresh token stored locally on your machine.

This is the send Gmail from Telegram capability we've been heads-down on since the TAB-678 EPIC. The full step-by-step setup lives in the new connect Gmail docs page.

What landed across these four releases

• TAB-684 (v2.3.148) — Three new Telegram commands. /connect_gmail opens the one-tap consent flow. /disconnect_gmail revokes locally and at Google. /email_status lists every connected account with last-used timestamps. State-aware entry-card text replaces the "drafts only" caveat with whichever message matches your current connection state.
• TAB-685 + TAB-686 + TAB-687 (v2.3.148) — Bundled email MCP server. A new codepulse-email-mcp.exe ships inside the installer. It reads your AES-256-GCM-encrypted refresh token from local SQLite, exchanges it for a short-lived access token, and calls Gmail's send endpoint directly — never through CodePulse infrastructure. Production logging covers every silent-degradation path; renderer alias means the approval card renders correctly whether Claude calls the tool by full name or short name.
• TAB-688 (v2.3.149) — Zero-config encryption key. CODEPULSE_CREDENTIAL_KEY is now auto-generated on first run and persisted to the per-install config. Previously you had to set it manually before connecting; now the install is genuinely zero-config.
• TAB-696 (v2.3.150) — Browser fallback link. The CONNECT_OPENING card now embeds the auth URL as a visible fallback link, so the small subset of Android setups whose Telegram "in-app browser" intercepts the system handoff can still complete the flow.
• TAB-697 (v2.3.151) — Auto-Return OAuth Bridge. The launchpad release. A three-innovation flow: Telegram WebApp for the scope-disclosure panel, Telegram.WebApp.openLink() to escape Google's WebView ban, and the t.me/<bot> universal link for an automatic return to Telegram after the user taps Allow on Google's consent screen. End-to-end connect takes about 25 seconds with no manual app-switching.

How to use it

/connect_gmail   → tap [Connect Gmail] → sign in → tap Allow → return to Telegram
/email_status    → see connected accounts + last-used timestamps
/disconnect_gmail → revoke locally and at Google in one step

After connecting, just talk to the bot: "email Sarah confirming Tuesday works" or "reply to my last email from John saying thanks." Every send produces an approval card with From / To / Cc / Bcc / Subject / Body visible. Tap Send to dispatch. Tap Cancel to abort.

Why this matters

CodePulse Real-life Mode could already read and draft email via the Anthropic Gmail Connector. What it could not do was send. Sending required the narrow gmail.send OAuth grant — which is not part of the Connector's scope and cannot be — so we built our own first-party OAuth client and bundled a tiny local MCP server to use it. Credentials never travel through CodePulse infrastructure. The OAuth bridge Worker is a one-tap handoff that sees nothing about your message content.

Every send goes through the HIGH_BLAST tier of the approval pipeline — the always-ASK tier that cannot be bypassed by learned auto-approve patterns. Of all the things an AI can do on your behalf, sending email is irreversible at a different scale than a Bash command or a code edit.

Beta reality

Until our CASA Tier 2 verification clears, the OAuth client runs in Google's Test User mode. Two practical consequences:

• Up to 100 specific Gmail addresses can connect during the beta. If Google shows you a "CodePulse is being tested" warning on the consent screen, your address has not been added to the testers list yet — email [email protected] with the Gmail you want to use.
• Refresh tokens expire every seven days. You will see a re-auth prompt in Telegram once a week until verification clears. Tap /connect_gmail again to refresh; no data is lost. Both limits go away in Phase 2.

What's next

Outlook send is Phase 3 — same one-tap connect flow, same always-ASK card, different OAuth provider. An App Password fallback for Workspace tenants with locked-down third-party OAuth is on the Phase 4 board. Linux and macOS builds with the bundled MCP land alongside the existing Windows installer once the cross-platform credential store has soaked.

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).

Breaking Changes

• Hook system rewritten: CodePulse now registers handlers for Claude Code's full hook event lifecycle instead of relying on basic notification interception. Run npm run install:hooks after updating to reconfigure hooks.
• Configuration format updated: The .env configuration has been restructured. Copy .env.example and migrate your Telegram token and chat ID.

New Features

• Commit Gate + AI Review: Every git commit Claude makes is intercepted before it lands. A fast AI model (Haiku) analyzes the diff and generates a human-readable summary of what changed and why. You see the analysis, the commit message, and the diff summary in Telegram, then choose to Approve, Reject, or Edit the commit message.
• Smart Classifier: Incoming Telegram messages are classified by intent. Approval responses go to the approval pipeline, direct instructions go to Claude Code, session queries trigger status reports. Prevents accidental command injection from unrelated chat messages.
• Voice Input: Send a Telegram voice message and it is transcribed via Whisper, then forwarded to Claude Code as a text instruction. Useful for sending instructions while away from your desk.
• Bidirectional Communication: Full two-way messaging between Telegram and Claude Code. Send instructions, ask questions, and receive Claude's responses directly in Telegram.
• Replay and Cost Intelligence: Token usage tracking per session and per project. AI-generated session replays that summarize what happened step by step. Cost calculations based on actual API pricing.
• Multi-Project Routing: Monitor multiple Claude Code sessions from a single Telegram group. Each project is routed to a separate Telegram topic for clean separation.

Improvements

• Batch Approval Cards: When Claude sends multiple rapid-fire permission requests, they are grouped into a single card instead of flooding your chat with individual messages.
• Auto-Approval Patterns: Expanded pattern matching for auto-approvals. Supports regex patterns, tool-specific rules, and project-scoped overrides.
• Session Stability: Resume-per-message architecture handles process crashes and restarts gracefully. If a Claude Code process exits unexpectedly, the next message resumes the session in a new process.
• Improved Error Handling: Hook failures are caught and reported to Telegram instead of silently failing. Network interruptions to the Telegram API are retried with exponential backoff.

Premium Tier

• Commit Gate with AI Review, Voice Input, and advanced cost analytics are available on the Premium plan ($4.99/month early bird). All other features are included in the free tier.