zcode-acp-server 0.34.0 → 0.35.1

package/dist/terminal-title.d.ts

@@ -0,0 +1,55 @@
+/**
+ * Terminal tab/window titles for TUI-hosted bridges (martty).
+ *
+ * martty never emits a terminal title, so a CLI-launched or hub-incubated
+ * window keeps whatever the shell last set — usually the command name — and a
+ * user with several windows cannot tell conversations apart. The bridge runs
+ * under martty in the same process group, so it shares the terminal's
+ * controlling tty and can name the tab itself with an OSC 0 sequence (the
+ * same escape the hub's TUI script prints at incubation time; this module
+ * keeps it live as the session gains a real title).
+ *
+ * Gated on `marttyClientSeen`: only a bridge spawned by a martty may write.
+ * A Zed extension host CAN have a controlling tty (Zed launched from a
+ * shell) — writing there would hijack an unrelated terminal's title, so
+ * non-martty bridges never write. Writes are rare (title lifecycle events,
+ * ~40 bytes) and OSC output is terminal chrome, not screen content, so they
+ * cannot corrupt martty's drawing beyond a single self-healing frame.
+ */
+import type { ZcodeAcpServer } from "./server.js";
+/**
+ * Strip everything a terminal title must not carry: C0/C1 controls and DEL
+ * (an embedded ESC or BEL could inject escape sequences; BEL also terminates
+ * the OSC string early), collapse whitespace runs, trim, cap.
+ */
+export declare function sanitizeTitle(raw: string): string;
+/** Injection seam for tests: write the OSC 0 sequence somewhere. */
+export interface TitleIo {
+    write(sequence: string): boolean;
+}
+/**
+ * The production writer: /dev/tty is the controlling terminal regardless of
+ * where stdout/stderr point (both are pipes to martty). Never throws — any
+ * failure means "no title support here" and is silently ignored. Also a hard
+ * no-op under vitest: a developer's test run shares their real terminal, and
+ * titles flashing by during `pnpm test` would be obnoxious.
+ */
+export declare const ttyTitleIo: TitleIo;
+/**
+ * The tab title for a session: `<project> · <topic>` once a conversation
+ * title is known (auto-title, adopted stored title, or rename), else the
+ * project directory name alone. The project is the folder basename, capped at
+ * PROJECT_MAX chars (ellipsis on cut) so an unwieldy dir name cannot crowd
+ * out the topic; when the combined title would exceed TITLE_MAX the TOPIC is
+ * trimmed to fit — the project anchors which window this is, the topic is
+ * the freshest information. The hub's incubation script builds the same
+ * string (ZCODE_ACP_TAB_TITLE), so the title never churns when the bridge
+ * takes over from the script's initial printf.
+ */
+export declare function sessionTabTitle(title: string | undefined, cwd: string | undefined): string;
+/**
+ * Push the current session title to the terminal tab (martty-hosted bridges
+ * only — see the module doc for why the gate is mandatory).
+ */
+export declare function refreshTerminalTabTitle(server: ZcodeAcpServer, acpSid: string, io?: TitleIo): boolean;
+//# sourceMappingURL=terminal-title.d.ts.map

package/dist/terminal-title.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"terminal-title.d.ts","sourceRoot":"","sources":["../src/terminal-title.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAKH,OAAO,KAAK,EAAE,cAAc,EAAE,MAAM,aAAa,CAAC;AAQlD;;;;GAIG;AACH,wBAAgB,aAAa,CAAC,GAAG,EAAE,MAAM,GAAG,MAAM,CAOjD;AAED,oEAAoE;AACpE,MAAM,WAAW,OAAO;IACtB,KAAK,CAAC,QAAQ,EAAE,MAAM,GAAG,OAAO,CAAC;CAClC;AAED;;;;;;GAMG;AACH,eAAO,MAAM,UAAU,EAAE,OAoBxB,CAAC;AAEF;;;;;;;;;;GAUG;AACH,wBAAgB,eAAe,CAAC,KAAK,EAAE,MAAM,GAAG,SAAS,EAAE,GAAG,EAAE,MAAM,GAAG,SAAS,GAAG,MAAM,CAe1F;AAED;;;GAGG;AACH,wBAAgB,uBAAuB,CACrC,MAAM,EAAE,cAAc,EACtB,MAAM,EAAE,MAAM,EACd,EAAE,GAAE,OAAoB,GACvB,OAAO,CAMT"}

package/dist/terminal-title.js

@@ -0,0 +1,114 @@
+/**
+ * Terminal tab/window titles for TUI-hosted bridges (martty).
+ *
+ * martty never emits a terminal title, so a CLI-launched or hub-incubated
+ * window keeps whatever the shell last set — usually the command name — and a
+ * user with several windows cannot tell conversations apart. The bridge runs
+ * under martty in the same process group, so it shares the terminal's
+ * controlling tty and can name the tab itself with an OSC 0 sequence (the
+ * same escape the hub's TUI script prints at incubation time; this module
+ * keeps it live as the session gains a real title).
+ *
+ * Gated on `marttyClientSeen`: only a bridge spawned by a martty may write.
+ * A Zed extension host CAN have a controlling tty (Zed launched from a
+ * shell) — writing there would hijack an unrelated terminal's title, so
+ * non-martty bridges never write. Writes are rare (title lifecycle events,
+ * ~40 bytes) and OSC output is terminal chrome, not screen content, so they
+ * cannot corrupt martty's drawing beyond a single self-healing frame.
+ */
+import { closeSync, openSync, writeSync } from "node:fs";
+import path from "node:path";
+import { log } from "./utils.js";
+/** Longest total title we ship; tab bars truncate visually anyway. */
+const TITLE_MAX = 100;
+/** Longest project (dir name) segment — the topic is the part worth reading. */
+const PROJECT_MAX = 24;
+/**
+ * Strip everything a terminal title must not carry: C0/C1 controls and DEL
+ * (an embedded ESC or BEL could inject escape sequences; BEL also terminates
+ * the OSC string early), collapse whitespace runs, trim, cap.
+ */
+export function sanitizeTitle(raw) {
+    const collapsed = raw
+        // eslint-disable-next-line no-control-regex
+        .replace(/[\u0000-\u001f\u007f-\u009f]+/g, " ")
+        .replace(/\s+/g, " ")
+        .trim();
+    return collapsed.length > TITLE_MAX ? collapsed.slice(0, TITLE_MAX - 1) + "…" : collapsed;
+}
+/**
+ * The production writer: /dev/tty is the controlling terminal regardless of
+ * where stdout/stderr point (both are pipes to martty). Never throws — any
+ * failure means "no title support here" and is silently ignored. Also a hard
+ * no-op under vitest: a developer's test run shares their real terminal, and
+ * titles flashing by during `pnpm test` would be obnoxious.
+ */
+export const ttyTitleIo = {
+    write(sequence) {
+        if (process.env.VITEST)
+            return false;
+        let fd;
+        try {
+            fd = openSync("/dev/tty", "w");
+            writeSync(fd, sequence);
+            return true;
+        }
+        catch {
+            return false;
+        }
+        finally {
+            if (fd !== undefined) {
+                try {
+                    closeSync(fd);
+                }
+                catch {
+                    // best-effort close
+                }
+            }
+        }
+    },
+};
+/**
+ * The tab title for a session: `<project> · <topic>` once a conversation
+ * title is known (auto-title, adopted stored title, or rename), else the
+ * project directory name alone. The project is the folder basename, capped at
+ * PROJECT_MAX chars (ellipsis on cut) so an unwieldy dir name cannot crowd
+ * out the topic; when the combined title would exceed TITLE_MAX the TOPIC is
+ * trimmed to fit — the project anchors which window this is, the topic is
+ * the freshest information. The hub's incubation script builds the same
+ * string (ZCODE_ACP_TAB_TITLE), so the title never churns when the bridge
+ * takes over from the script's initial printf.
+ */
+export function sessionTabTitle(title, cwd) {
+    const cwdTrimmed = (cwd ?? "").trim();
+    // Both segments are sanitized: the cwd is CLIENT-supplied (a remote client
+    // controls its session/new cwd), and a dirname containing ESC/BEL would
+    // otherwise flow raw into the OSC payload (arbitrary OSC injection, e.g.
+    // clipboard writes). sanitizeTitle also collapses the length cap below.
+    let project = cwdTrimmed ? sanitizeTitle(path.basename(cwdTrimmed)) : "";
+    if (project.length > PROJECT_MAX)
+        project = project.slice(0, PROJECT_MAX - 1) + "…";
+    if (!project)
+        project = "zcode";
+    const topic = sanitizeTitle(title ?? "");
+    if (!topic)
+        return project;
+    // PROJECT_MAX keeps this comfortably positive (100 - 24 - 3).
+    const budget = TITLE_MAX - project.length - 3;
+    const fitTopic = topic.length > budget ? topic.slice(0, budget - 1) + "…" : topic;
+    return `${project} · ${fitTopic}`;
+}
+/**
+ * Push the current session title to the terminal tab (martty-hosted bridges
+ * only — see the module doc for why the gate is mandatory).
+ */
+export function refreshTerminalTabTitle(server, acpSid, io = ttyTitleIo) {
+    if (!server.marttyClientSeen)
+        return false;
+    const title = sessionTabTitle(server.sessionTitles.get(acpSid), server.sessionCwds.get(acpSid));
+    const ok = io.write(`\x1b]0;${title}\x07`);
+    if (!ok)
+        log(`terminal title not written (no tty or unsupported)`);
+    return ok;
+}
+//# sourceMappingURL=terminal-title.js.map

package/dist/terminal-title.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"terminal-title.js","sourceRoot":"","sources":["../src/terminal-title.ts"],"names":[],"mappings":"AAAA;;;;;;;;;;;;;;;;;GAiBG;AAEH,OAAO,EAAE,SAAS,EAAE,QAAQ,EAAE,SAAS,EAAE,MAAM,SAAS,CAAC;AACzD,OAAO,IAAI,MAAM,WAAW,CAAC;AAG7B,OAAO,EAAE,GAAG,EAAE,MAAM,YAAY,CAAC;AAEjC,sEAAsE;AACtE,MAAM,SAAS,GAAG,GAAG,CAAC;AACtB,gFAAgF;AAChF,MAAM,WAAW,GAAG,EAAE,CAAC;AAEvB;;;;GAIG;AACH,MAAM,UAAU,aAAa,CAAC,GAAW;IACvC,MAAM,SAAS,GAAG,GAAG;QACnB,4CAA4C;SAC3C,OAAO,CAAC,gCAAgC,EAAE,GAAG,CAAC;SAC9C,OAAO,CAAC,MAAM,EAAE,GAAG,CAAC;SACpB,IAAI,EAAE,CAAC;IACV,OAAO,SAAS,CAAC,MAAM,GAAG,SAAS,CAAC,CAAC,CAAC,SAAS,CAAC,KAAK,CAAC,CAAC,EAAE,SAAS,GAAG,CAAC,CAAC,GAAG,GAAG,CAAC,CAAC,CAAC,SAAS,CAAC;AAC5F,CAAC;AAOD;;;;;;GAMG;AACH,MAAM,CAAC,MAAM,UAAU,GAAY;IACjC,KAAK,CAAC,QAAgB;QACpB,IAAI,OAAO,CAAC,GAAG,CAAC,MAAM;YAAE,OAAO,KAAK,CAAC;QACrC,IAAI,EAAsB,CAAC;QAC3B,IAAI,CAAC;YACH,EAAE,GAAG,QAAQ,CAAC,UAAU,EAAE,GAAG,CAAC,CAAC;YAC/B,SAAS,CAAC,EAAE,EAAE,QAAQ,CAAC,CAAC;YACxB,OAAO,IAAI,CAAC;QACd,CAAC;QAAC,MAAM,CAAC;YACP,OAAO,KAAK,CAAC;QACf,CAAC;gBAAS,CAAC;YACT,IAAI,EAAE,KAAK,SAAS,EAAE,CAAC;gBACrB,IAAI,CAAC;oBACH,SAAS,CAAC,EAAE,CAAC,CAAC;gBAChB,CAAC;gBAAC,MAAM,CAAC;oBACP,oBAAoB;gBACtB,CAAC;YACH,CAAC;QACH,CAAC;IACH,CAAC;CACF,CAAC;AAEF;;;;;;;;;;GAUG;AACH,MAAM,UAAU,eAAe,CAAC,KAAyB,EAAE,GAAuB;IAChF,MAAM,UAAU,GAAG,CAAC,GAAG,IAAI,EAAE,CAAC,CAAC,IAAI,EAAE,CAAC;IACtC,2EAA2E;IAC3E,wEAAwE;IACxE,yEAAyE;IACzE,wEAAwE;IACxE,IAAI,OAAO,GAAG,UAAU,CAAC,CAAC,CAAC,aAAa,CAAC,IAAI,CAAC,QAAQ,CAAC,UAAU,CAAC,CAAC,CAAC,CAAC,CAAC,EAAE,CAAC;IACzE,IAAI,OAAO,CAAC,MAAM,GAAG,WAAW;QAAE,OAAO,GAAG,OAAO,CAAC,KAAK,CAAC,CAAC,EAAE,WAAW,GAAG,CAAC,CAAC,GAAG,GAAG,CAAC;IACpF,IAAI,CAAC,OAAO;QAAE,OAAO,GAAG,OAAO,CAAC;IAChC,MAAM,KAAK,GAAG,aAAa,CAAC,KAAK,IAAI,EAAE,CAAC,CAAC;IACzC,IAAI,CAAC,KAAK;QAAE,OAAO,OAAO,CAAC;IAC3B,8DAA8D;IAC9D,MAAM,MAAM,GAAG,SAAS,GAAG,OAAO,CAAC,MAAM,GAAG,CAAC,CAAC;IAC9C,MAAM,QAAQ,GAAG,KAAK,CAAC,MAAM,GAAG,MAAM,CAAC,CAAC,CAAC,KAAK,CAAC,KAAK,CAAC,CAAC,EAAE,MAAM,GAAG,CAAC,CAAC,GAAG,GAAG,CAAC,CAAC,CAAC,KAAK,CAAC;IAClF,OAAO,GAAG,OAAO,MAAM,QAAQ,EAAE,CAAC;AACpC,CAAC;AAED;;;GAGG;AACH,MAAM,UAAU,uBAAuB,CACrC,MAAsB,EACtB,MAAc,EACd,KAAc,UAAU;IAExB,IAAI,CAAC,MAAM,CAAC,gBAAgB;QAAE,OAAO,KAAK,CAAC;IAC3C,MAAM,KAAK,GAAG,eAAe,CAAC,MAAM,CAAC,aAAa,CAAC,GAAG,CAAC,MAAM,CAAC,EAAE,MAAM,CAAC,WAAW,CAAC,GAAG,CAAC,MAAM,CAAC,CAAC,CAAC;IAChG,MAAM,EAAE,GAAG,EAAE,CAAC,KAAK,CAAC,UAAU,KAAK,MAAM,CAAC,CAAC;IAC3C,IAAI,CAAC,EAAE;QAAE,GAAG,CAAC,oDAAoD,CAAC,CAAC;IACnE,OAAO,EAAE,CAAC;AACZ,CAAC"}

package/docs/ARCHITECTURE.md

@@ -318,8 +318,10 @@ zcode interaction request received
   │     └─ Always uses session/request_permission (its native purpose)
   │
   ├─ ExitPlanMode (interaction/requestUserInput + plan_approval)
-  │     ├─ Client supports elicitation.form → elicitation/create (approve/reject form)
-  │     └─ Otherwise → session/request_permission (fallback)
+  │     ├─ martty attached (hasMarttyClient) → elicitation/create (approve/reject form;
+  │     │     its permission overlay draws only the title — the plan needs the form)
+  │     └─ Otherwise → session/request_permission (editors render toolCall.content
+  │           as full markdown; elicitation form descriptions are plain text there)
   │
   └─ AskUserQuestion (interaction/requestUserInput)
         ├─ Client supports elicitation.form → elicitation/create (single form)
@@ -327,8 +329,11 @@ zcode interaction request received
 ```
 
 **Key**: `server.supportsElicitationForm()` is detected at `initialize` time from
-`clientCapabilities.elicitation.form`. Tool auth always goes through
-request_permission, since that is its native purpose.
+`clientCapabilities.elicitation.form` (AskUserQuestion). ExitPlanMode keys on
+`server.hasMarttyClient()` instead — Zed ≥1.12 declares `elicitation.form` too,
+but its form descriptions are plain text while its permission popups render
+`toolCall.content` as markdown, so only martty benefits from the form. Tool auth
+always goes through request_permission, since that is its native purpose.
 
 ## Deferred Notification Mechanism
 

package/docs/PROTOCOL.md

@@ -566,17 +566,24 @@ User input request (ExitPlanMode / AskUserQuestion).
 ### Bridge routing (protocol negotiation)
 
 ZCode `interaction/*` requests are routed to different ACP interaction
-mechanisms based on client capabilities:
-
-| Request type                                                  |      Client supports elicitation.form      |              Client does not              |
-| ------------------------------------------------------------- | :----------------------------------------: | :---------------------------------------: |
-| Tool auth (`interaction/requestPermission`)                   |        `session/request_permission`        |       `session/request_permission`        |
-| ExitPlanMode (`interaction/requestUserInput` + plan_approval) | `elicitation/create` (approve/reject form) |       `session/request_permission`        |
-| AskUserQuestion (`interaction/requestUserInput`)              |     `elicitation/create` (single form)     | per-question `session/request_permission` |
-
-**Capability detection**: at `initialize` time the client declares support via
-`clientCapabilities.elicitation.form`. The server detects it with
-`server.supportsElicitationForm()`.
+mechanisms. Each request type has its OWN gate:
+
+| Request type                                                  |       Routing when the gate is OPEN        |      Routing when the gate is CLOSED      | Gate                               |
+| ------------------------------------------------------------- | :----------------------------------------: | :---------------------------------------: | :--------------------------------- |
+| Tool auth (`interaction/requestPermission`)                   |        `session/request_permission`        |       `session/request_permission`        | none (always the same path)        |
+| ExitPlanMode (`interaction/requestUserInput` + plan_approval) | `elicitation/create` (approve/reject form) |       `session/request_permission`        | `server.hasMarttyClient()`         |
+| AskUserQuestion (`interaction/requestUserInput`)              |     `elicitation/create` (single form)     | per-question `session/request_permission` | `server.supportsElicitationForm()` |
+
+**Capability detection**: AskUserQuestion keys on
+`clientCapabilities.elicitation.form` (detected at `initialize` via
+`server.supportsElicitationForm()`) — structured input is the correct
+elicitation use for any form-capable client. ExitPlanMode keys on
+`server.hasMarttyClient()` instead: martty's request_permission overlay draws
+only the title, so the plan needs the form's scrollable detail pane — while
+editors render `toolCall.content` as full markdown (Zed: `MarkdownElement`,
+code blocks and links) and draw form descriptions as plain text, so the form
+would downgrade them. Zed ≥1.12 declares `elicitation.form`, which is why the
+gate keys on the client kind, not the capability.
 
 **Reconnect resend**: interaction requests are one-shot and raced across the
 clients connected when they fire (first response wins). A client that was
@@ -638,10 +645,10 @@ that question without cancelling the form.
 }
 ```
 
-**ExitPlanMode elicitation form** — sent only to clients that advertised
-elicitation form support; everyone else gets `session/request_permission` with
-the plan in `toolCall.content`. The form carries the COMPLETE plan markdown as
-the `approval` field's `description` (markdown-capable clients render it in a
+**ExitPlanMode elicitation form** — sent only when a martty TUI is attached
+(`server.hasMarttyClient()`); everyone else gets `session/request_permission`
+with the plan in `toolCall.content`. The form carries the COMPLETE plan
+markdown as the `approval` field's `description` (martty renders it in a
 scrollable detail pane); the decision itself is a required approve/reject enum.
 An `accept` whose `content.approval` is `"approve"` maps to the zcode accept
 (`answer_0: "approve"`); a `reject`/`cancel` action, or `"reject"` in the

package/docs/TROUBLESHOOTING.md

@@ -67,13 +67,13 @@ a hardcoded version string — read the message text to identify the root cause.
 
 **Common causes:**
 
-| Message fragment                 | Cause                                                                                                                                                                                                                                                      |
-| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `reader exited (backend dead)`   | The zcode subprocess crashed/exited. Restart the editor session.                                                                                                                                                                                           |
-| `timeout`                        | The per-attempt 5s subscribe deadline elapsed. The bridge retries transient timeouts once (2 attempts total, ~10.5s worst case); if both fail, the backend was unresponsive for that window.                                                               |
-| `pipe broken`                    | The stdin pipe to the zcode subprocess broke (process died mid-write).                                                                                                                                                                                     |
-| `method not found (code -32601)` | The CLI genuinely is too old (< 0.14.8). Upgrade.                                                                                                                                                                                                          |
-| `Session is not active` (-32004) | The backend evicted the session's resident runtime (idle ~10min, or its LRU cap). The bridge self-heals via `session/resume` (see below).                                                                                                                   |
+| Message fragment                 | Cause                                                                                                                                                                                        |
+| -------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `reader exited (backend dead)`   | The zcode subprocess crashed/exited. Restart the editor session.                                                                                                                             |
+| `timeout`                        | The per-attempt 5s subscribe deadline elapsed. The bridge retries transient timeouts once (2 attempts total, ~10.5s worst case); if both fail, the backend was unresponsive for that window. |
+| `pipe broken`                    | The stdin pipe to the zcode subprocess broke (process died mid-write).                                                                                                                       |
+| `method not found (code -32601)` | The CLI genuinely is too old (< 0.14.8). Upgrade.                                                                                                                                            |
+| `Session is not active` (-32004) | The backend evicted the session's resident runtime (idle ~10min, or its LRU cap). The bridge self-heals via `session/resume` (see below).                                                    |
 
 **`Session is not active` (code -32004) in detail:**
 
@@ -182,6 +182,10 @@ log (`~/.zcode/cli/log/zcode-YYYY-MM-DD.jsonl`) for the underlying cause
    - `⟳ AskUserQuestion forwarding elicitation/create (form, N fields)` → elicitation path
    - `⟳ AskUserQuestion forwarding session/request_permission` → fallback path
    - The path is decided by `clientCapabilities.elicitation.form`
+   - ExitPlanMode has its own gate: `⟳ ExitPlanMode forwarding elicitation/create` only
+     fires when `hasMarttyClient` is true (a martty TUI attached to this bridge — the
+     flag is sticky for the process lifetime); other clients take
+     `session/request_permission` (their popups render the plan markdown)
 
 3. Check whether `askOnce` (fallback path) or `handleAskUserViaElicitation`
    (elicitation path) successfully sent the request:
@@ -382,6 +386,26 @@ re-registered from the durable store without a resume (or left behind by a
 failed one) therefore replayed nothing. Fixed by explicit backend-loaded
 tracking; the backend also logs a warning now when `session/messages` errors.
 
+### Remote access: a conversation replays only PARTLY on first entry
+
+**Symptom:** entering a resumed conversation the FIRST time shows history
+that ends in the middle; leaving and re-entering shows the full conversation.
+Happens often (but not always) with large sessions.
+
+**Cause:** the hub answers the resume request as soon as the incubated
+terminal bridge registers — before the terminal's boot-resume finishes — so
+the App's `session/load` raced the boot-resume for the SAME backend session.
+Both sent `session/resume` concurrently, and `session/messages` reflects only
+what the backend has hydrated so far: a query landing mid-restore returns a
+PREFIX, which was replayed as if it were the whole conversation. Fixed by
+single-flighting `session/resume` TOGETHER WITH its hydration settle per
+backend session id (a concurrent load joins the in-flight flight and shares
+its settled history snapshot; the settle requires two consecutive
+non-growing reads, capped). The bridge log line
+`session/load: replayed N messages (total M)` now prints the total
+unconditionally — a first-entry total below the session's real size was the
+signature of this bug.
+
 ### Start Plan (zcode-plan) providers fail headless — 1113 / signing errors
 
 **Symptom:** every turn fails with HTTP 429 error `1113` ("Insufficient
@@ -433,6 +457,38 @@ tool output contains `Operation not permitted` — that warning is your signal
 to suspect the sandbox. Path grants for legitimate writes go in
 `.zcode/acp/sandbox.json`.
 
+### UNRESOLVED: CLI (martty) freezes at an old state while the mobile app keeps updating
+
+**Symptom (observed once, 2026-09, no live instance preserved):** a CLI window
+attached to a conversation stops receiving everything — messages, model
+dropdown, thought-level updates — while the mobile app on the same
+conversation keeps receiving and interacting normally. The CLI stays frozen at
+a state noticeably older than the conversation.
+
+**Working hypotheses (in rough likelihood order), none confirmed:**
+
+1. **Session-alias divergence** — the interaction moved to an ACP session id
+   the martty connection never adopted (e.g. a phone-side `session/new` racing
+   the window's binding). martty drops every update addressed to a session id
+   it does not know (same failure shape as the 2026-09-06 boot-create
+   diagnosis in AGENTS.md). Everything stalling at once — config updates
+   included — fits a sessionId mismatch, since all of them are session-scoped.
+2. **Two different bridge processes** — the phone attached to the hub's serve
+   bridge while the CLI runs its own bridge: live events do not cross
+   processes by design (only session listings do). The CLI then only ever
+   updates for its own turns.
+3. **martty stdio wedge** — the TUI's own input thread stalls; the bridge's
+   notifies buffer into the pipe and the mobile (WS path) is unaffected.
+   Bridge-side nothing is wrong; typing in the frozen CLI would also be dead.
+
+**If it recurs, capture before closing anything:** whether typing still works
+in the frozen CLI (separates hypothesis 3 from 1/2); the bridge's stderr with
+`ZCODE_ACP_DEBUG=1` (do `session/update` notifies still leave?); the hub's
+instance listing (`GET /api/instances`) — which bridge id the phone's
+conversation is on vs the CLI's; and both ends' session ids (CLI transcript vs
+phone). See also the resume-race diagnosis in the same period: a partial
+first-entry replay is a different bug (history prefix), do not conflate.
+
 ## Log Debugging
 
 ### Enable verbose logging

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "zcode-acp-server",
-  "version": "0.34.0",
+  "version": "0.35.1",
   "description": "Agent Client Protocol (ACP) server bridging headless ZCode to editors like Zed and JetBrains.",
   "type": "module",
   "license": "Apache-2.0",