@code-yeongyu/senpi 2026.9.29-5 → 2026.9.30

package/dist/runtime-snapshot/registry.d.ts

@@ -4,6 +4,13 @@ export declare const UNUSED_SNAPSHOT_GRACE_MS: number;
  * The lock is a directory, so creating it is atomic on every platform and filesystem.
  */
 export declare function withRuntimeLock<T>(root: string, task: () => T): T | undefined;
+/**
+ * Runs `build` as the only builder of snapshot `id`; undefined when another live builder keeps it
+ * past the wait. Building a snapshot copies thousands of files, so it runs under its own lock, not
+ * the runtime root's, and never blocks launches of snapshots that already exist. A lock whose
+ * holder died is taken over, and the dead builder's staging directories are removed first.
+ */
+export declare function withBuildLock<T>(root: string, id: string, build: () => Promise<T>, isAlive?: (pid: number) => boolean): Promise<T | undefined>;
 export declare function isProcessAlive(pid: number): boolean;
 export declare function claimRuntimeSnapshot(snapshotDir: string, pid: number): void;
 /**

package/dist/runtime-snapshot/registry.js

@@ -1,11 +1,17 @@
-import { mkdirSync, readdirSync, renameSync, rmSync, statSync, unlinkSync, utimesSync, writeFileSync } from "node:fs";
+import { mkdirSync, readdirSync, readFileSync, renameSync, rmSync, statSync, unlinkSync, utimesSync, writeFileSync, } from "node:fs";
 import { join } from "node:path";
+import { STAGING_PREFIX } from "./layout.js";
 import { RUNTIME_SNAPSHOT_MARKER } from "./marker.js";
 const LOCK_NAME = ".lock";
 const CLAIMS_DIR = "claims";
 const STALE_LOCK_MS = 30_000;
 const LOCK_WAIT_MS = 5_000;
 const LOCK_RETRY_MS = 25;
+const BUILD_LOCK_PREFIX = ".build-";
+const BUILD_WAIT_MS = 120_000;
+const BUILD_RETRY_MS = 50;
+/** A build lock whose holder never wrote its pid (it died right after creating it). */
+const UNOWNED_BUILD_LOCK_MS = 30_000;
 export const UNUSED_SNAPSHOT_GRACE_MS = 10 * 60_000;
 const LEFTOVER_MS = 60 * 60_000;
 function errorCode(error) {
@@ -58,6 +64,62 @@ export function withRuntimeLock(root, task) {
         rmSync(lock, { recursive: true, force: true });
     }
 }
+function buildLockHolder(lock) {
+    try {
+        const pid = Number(readFileSync(join(lock, "pid"), "utf8"));
+        return Number.isSafeInteger(pid) && pid > 0 ? pid : undefined;
+    }
+    catch (error) {
+        if (errorCode(error) === "ENOENT" || errorCode(error) === "ENOTDIR")
+            return undefined;
+        throw error;
+    }
+}
+function isAbandonedBuildLock(lock, now, isAlive) {
+    const holder = buildLockHolder(lock);
+    return holder === undefined ? ageMs(lock, now) > UNOWNED_BUILD_LOCK_MS : !isAlive(holder);
+}
+/**
+ * Runs `build` as the only builder of snapshot `id`; undefined when another live builder keeps it
+ * past the wait. Building a snapshot copies thousands of files, so it runs under its own lock, not
+ * the runtime root's, and never blocks launches of snapshots that already exist. A lock whose
+ * holder died is taken over, and the dead builder's staging directories are removed first.
+ */
+export async function withBuildLock(root, id, build, isAlive = isProcessAlive) {
+    mkdirSync(root, { recursive: true });
+    const lock = join(root, `${BUILD_LOCK_PREFIX}${id}`);
+    const deadline = Date.now() + BUILD_WAIT_MS;
+    for (;;) {
+        try {
+            mkdirSync(lock);
+            writeFileSync(join(lock, "pid"), String(process.pid));
+            break;
+        }
+        catch (error) {
+            if (errorCode(error) !== "EEXIST")
+                throw error;
+        }
+        if (isAbandonedBuildLock(lock, Date.now(), isAlive)) {
+            rmSync(lock, { recursive: true, force: true });
+        }
+        else if (Date.now() > deadline) {
+            return undefined;
+        }
+        else {
+            sleepSync(BUILD_RETRY_MS);
+        }
+    }
+    try {
+        for (const name of readdirSync(root)) {
+            if (name.startsWith(`${STAGING_PREFIX}${id}-`))
+                rmSync(join(root, name), { recursive: true, force: true });
+        }
+        return await build();
+    }
+    finally {
+        rmSync(lock, { recursive: true, force: true });
+    }
+}
 export function isProcessAlive(pid) {
     try {
         process.kill(pid, 0);

package/dist/senpi

@@ -168,7 +168,7 @@ else {
     // an upgrade that rewrites the install cannot remove chunks this session imports later (#2358).
     const entryPath = fileURLToPath(import.meta.url);
     const snapshot = isBundledNode
-        ? prepareRuntimeSnapshot(entryPath, findNodePackageDir(dirname(entryPath)), getAgentDir())
+        ? await prepareRuntimeSnapshot(entryPath, findNodePackageDir(dirname(entryPath)), getAgentDir())
         : undefined;
     if (snapshot?.kind === "hand-off") {
         await import(__rewriteRelativeImportExtension(snapshot.entryUrl));

package/docs/providers.md

@@ -101,7 +101,7 @@ If your Claude Pro/Max subscription usage through `anthropic-subscription` feels
 
    | Lane | Effective TTL | Who controls it | How to override |
    | --- | --- | --- | --- |
-   | Anthropic Subscription (subscription, `anthropic-subscription`) | 5 minutes | The Claude SDK owns `cache_control`; senpi cannot add breakpoints. senpi reports 300s for this lane so cache-aware budgets (tool waits, goal timing) size themselves correctly. | Not overridable |
+   | Anthropic Subscription (subscription, `anthropic-subscription`) | 1 hour on a Claude subscription; 5 minutes when `ANTHROPIC_API_KEY`, `ANTHROPIC_AUTH_TOKEN`, `ANTHROPIC_BASE_URL` or a Bedrock/Vertex/Foundry switch is set | Claude Code owns `cache_control` and picks the TTL; senpi cannot add breakpoints. senpi reports the same TTL so cache-aware budgets (tool waits, goal timing) size themselves correctly. A subscription past its usage limits drops to 5 minutes, which senpi cannot observe. | `CLAUDE_CODE_PROMPT_CACHE_TTL=5m` or `1h` (also read by Claude Code) |
    | Direct Anthropic API (`api.anthropic.com`, API key or OAuth token) | 5 minutes | senpi follows Anthropic's default cache retention. Opting into 1h retention makes cache writes cost 2x base input vs 1.25x for 5m ([Anthropic prompt caching](https://docs.claude.com/en/docs/build-with-claude/prompt-caching)). | Set `PI_CACHE_RETENTION=long` or `cacheRetention: "long"` |
    | Anthropic-compatible providers (kimi-coding, fireworks, gateways) | 5 minutes | The 1h TTL is gated on the native `api.anthropic.com` base URL, so these lanes stay short. | `cacheRetention` |
 

package/docs/rpc.md

@@ -753,15 +753,21 @@ Where a session's replies render decides its system prompt. `terminal` is the cl
 shows replies as chat, such as the OmO Desktop) keeps the same intent routing and stop-condition rules but asks for no
 visible `I read this as ...` routing line, and tells the agent that tool and hook feedback (comment-checker findings,
 language-server availability, internal notices) is for it to act on, not to report unless it changes the result.
+`chat` (a chat bridge that posts each reply to people in a conversation) takes every `app` rule and also drops the
+handoff block and todo/ledger lines: the reply is the answer itself, and the todo tool emits no "Handoff due" cue.
+As a backstop, the `chat-reply-scrub` builtin removes a leading routing line, a handoff block and todo-ledger lines
+from each finalized assistant message on `chat` before it is emitted or persisted; streamed `message_update` deltas are
+not rewritten.
 
-A multi-session host decides the surface per session: `open_session.promptSurface: "terminal" | "app"` builds that
+A multi-session host decides the surface per session: `open_session.promptSurface: "terminal" | "app" | "chat"` builds that
 session's prompt for the named surface, so one host serves a terminal client and an app client at once. An omitted field
-uses the host process's `SENPI_PROMPT_SURFACE` (`app` selects the app surface; unset or any other value is `terminal`),
+uses the host process's `SENPI_PROMPT_SURFACE` (`app` or `chat` selects that surface; unset or any other value is `terminal`),
 which remains the only switch for a single-process `--mode rpc` client. A later `open_session` that attaches to a live
 session with another `promptSurface` rebuilds that session's prompt; an attach without the field keeps the current
 surface, and `new_session` / `switch_session` / `fork` inside the session keep it too. Probe `prompt_surface` in
-`get_protocol_info` before sending the field; an older host ignores it. Any value other than `terminal` or `app` is
-refused with `invalid_launch_profile`.
+`get_protocol_info` before sending the field; an older host ignores it. Probe `prompt_surface_chat` before sending
+`chat`: a host without it refuses `chat` with `invalid_launch_profile`, so a gateway falls back to `app`. Any value other
+than `terminal`, `app` or `chat` is refused with `invalid_launch_profile`.
 
 ### Session auto-titling
 
@@ -998,9 +1004,10 @@ registrant opens no socket and writes no registry directory.
     still holds after it.
   - `wake { delivery_ids? }`: one drain pass, answered `{ admitted: [{ delivery_id, kind }] }`.
   - `extension_ui_response`: answers only a question this session asked and still waits on
-    (`unknown_request` / `invalid_response` otherwise). `uiRequestId` names the question (a pending
-    question id from the `question` feed); without it, `id` does. The reply carries the frame's `id`,
-    as on a host (see "Extension UI Responses").
+    (`unknown_request` / `question_incomplete` / `invalid_response` otherwise). `uiRequestId` names the
+    question (a pending question id from the `question` feed); without it, `id` does. The answer settles by
+    the host's rule (see `question`) and the reply carries the frame's `id`, as on a host (see "Extension
+    UI Responses").
   - `prompt`, `steer` and `follow_up` are `unsupported`.
 - **Admission.** A message from another session enters only through the registrant's drain, which calls
   `pi.session.admitExternalMessage({ delivery_id, text, deliverAs, expected_turn_id? })`. One synchronous call
@@ -1283,9 +1290,15 @@ containment, or containment of arbitrary native code. They are not an extension
 
 ### D1 normative table (multi-session mode)
 
+Hosts that support `open_session.permissionPreset: "accept-edits"` advertise
+`permission_preset_accept_edits`. This preset allows project read/list/grep/edit
+and asks for bash, external_directory and other tools. Clients without that
+capability must use `ask`, never `workspace`, for an edit-only approval promise.
+Explicit permission rules and remembered approvals retain their existing precedence.
+
 | Command | Params | Success data | Notes |
 | --- | --- | --- | --- |
-| `get_protocol_info` | - | `{ protocolVersion: 1, serverVersion: string, capabilities: string[], mode: "classic"\|"multi", instanceId: string, generation: number, engineVersion: string, engineOrdinal: [y, m, d, n, epoch], launch_profile: { profile_id, core }, memory_pressure?: boolean }` | Answered in BOTH modes; side-effect-free; the capability probe. Multi-session hosts include `multi_session`, `retain_on_disconnect`, `session_kind`, `session_context`, `auto_title_per_session`, `durable_session_id` and `prompt_surface` plus the negotiated launch capabilities. Those are HOST capabilities (a client never sends them) and are advertised only in multi-session mode, where the host owns the attachment refcount and the per-session launch profile. The identity fields are described under "Host identity" above; compatibility is decided from `protocolVersion`, `capabilities` and `engineOrdinal`, NEVER from `serverVersion`. |
+| `get_protocol_info` | - | `{ protocolVersion: 1, serverVersion: string, capabilities: string[], mode: "classic"\|"multi", instanceId: string, generation: number, engineVersion: string, engineOrdinal: [y, m, d, n, epoch], launch_profile: { profile_id, core }, memory_pressure?: boolean }` | Answered in BOTH modes; side-effect-free; the capability probe. Multi-session hosts include `multi_session`, `retain_on_disconnect`, `session_kind`, `session_context`, `auto_title_per_session`, `durable_session_id`, `prompt_surface` and `prompt_surface_chat` plus the negotiated launch capabilities. Those are HOST capabilities (a client never sends them) and are advertised only in multi-session mode, where the host owns the attachment refcount and the per-session launch profile. The identity fields are described under "Host identity" above; compatibility is decided from `protocolVersion`, `capabilities` and `engineOrdinal`, NEVER from `serverVersion`. |
 | `open_session` | `sessionPath?`, `cwd?`, `provider?`, `modelId?`, `thinkingLevel?`, `permissionPreset?`, `retain_on_disconnect?`, `kind?`, `context?`, `auto_title?`, `durableSessionId?`, `promptSurface?` (all optional; paths MUST be absolute) | `{ sessionId, state: RpcSessionState, attached?: true }` | `sessionPath` = today's `--session` semantics (open-if-exists else create persisting there, `session-manager.ts:926-940`); `provider`/`modelId` applied only on create (resume restores the session's model — mirrors `SenpiSessionRuntime.ts:198-200`); params form the immutable launch profile (D8). When the path is already held by a fully-open session, the open ATTACHES to it: same routing handle, `attached: true`, one more attachment counted; the runtime is torn down only when the last attachment closes. Idle sessions past the eviction window are closed by the host itself. `retain_on_disconnect: true` (default false) makes a dropped connection DETACH from this session instead of closing it — see "Retained sessions" below. `kind` (default `interactive`) and the opaque `context` map are described under "Session kind and context" above; both are stored frozen for the session's life and never influence auth, model or resource resolution. |
 | `close_session` | `sessionId` | `{}` | Refused with `unknown_session` when the requesting connection never attached to that handle (a close releases the CALLER's attachment, and `list_sessions` publishes every handle). Otherwise aborts active work, awaits agent idle + settled persistence for up to the host grace window (default 10s), then quarantines any worker that has not exited without releasing its path reservation; its response is the LAST record tagged with that handle for the first closer — no events after (test-pinned). An admitted concurrent close joins the same teardown and receives its own successful response; output saturation rejects admission with the bounded close-overflow/resync notice described above. |
 | `list_sessions` | `include_workers?` (default false) | `{ sessions: [{ sessionId, durableSessionId, sessionPath, cwd, name, status, attachments, kind, context? }] }` | Includes `opening`/`closing` entries. Internally quarantined workers remain externally `closing` until exit. `attachments` is the session's live client attachment count; `0` on an `open` row is a retained session with no client attached. Every row carries `kind`. Rows with `kind: "worker"` are omitted unless `include_workers: true`, and `context` is published ONLY on that listing — a default listing carries no `context` at all. |
@@ -1319,7 +1332,7 @@ In the response `error` field, machine-matchable:
 - `open_failed: <detail>`
 - `invalid_session_context: <detail>` (`open_session.context` past a documented cap: more than 32 keys, a key that does not match `^[a-z][a-z0-9_]*$`, a non-string or >16 KiB value, or more than 32 KiB of JSON in total; the detail names the cap and its byte budget)
 - `invalid_session_kind: <detail>` (`open_session.kind` other than `interactive` or `worker`)
-- `invalid_launch_profile: <detail>` (`open_session.auto_title` present but not a boolean, or `open_session.promptSurface` other than `terminal` or `app`)
+- `invalid_launch_profile: <detail>` (`open_session.auto_title` present but not a boolean, or `open_session.promptSurface` other than `terminal`, `app` or `chat`)
 - `host_memory_pressure` (sent only by hosts released before #2207, which declined to CREATE a `kind: "worker"` session above `SENPI_RPC_HOST_RSS_REFUSE_MB`; `errorData { rssMb, retry_after_ms }` says when to ask again. Current hosts never refuse an open for memory; a client talking to an older generation waits and retries, it never starts a second host or a per-child process)
 - `warm_failed: <detail>` (`warm` could not load its profile, for example a `cwd` that does not exist; not remembered, so a retry loads again)
 - `media_not_found` (`get_media` for an unknown `toolCallId`, or a `contentIndex` that does not point at an image block)
@@ -3407,7 +3420,17 @@ Present one or more questions to the user. Requires the `question` client capabi
 }
 ```
 
-Expected response: `extension_ui_response` with `answers` (a map of question id to `{ selected: string[], text?: string }`) and an optional `comment`. Partial answers are allowed: unanswered question ids are reported back to the model. Send `cancelled: true` to dismiss.
+Expected response: `extension_ui_response` with `answers` (a map of question id to `{ selected: string[], text?: string }`) and an optional `comment`. Partial answers are allowed: the model is told which questions went unanswered, by header. Send `cancelled: true` to dismiss.
+
+A multi-session host and a terminal control endpoint settle a `question` answer by one rule, so the same frame reaches the model as the same message on either surface:
+
+- `cancelled: true` dismisses the question.
+- Otherwise `answers` and `comment` are read; a `value` or `confirmed` in the same frame belongs to the other dialog methods and is ignored.
+- A non-blank `comment` settles it `comment-submitted`: the model receives `The user responded: <comment>`, then any answered questions and the headers of the unanswered ones (`Unanswered: <header>, ...`). A frame that carries its text only as `comment` with `answers: {}` is a complete answer.
+- Without a comment, any entry in `answers` settles it `answered`.
+- Neither a non-blank comment nor an answer is refused `question_incomplete`, and the question stays pending.
+
+A terminal refuses a frame whose `answers` is missing or malformed with `invalid_response`.
 
 While the question is open, the client may send `extension_ui_progress` frames with draft `answers` and `comment`. Each progress frame resets the idle timer; the host emits `question_updated` with the refreshed `deadlineAtMs` and `remainingMs`.
 
@@ -3454,7 +3477,7 @@ carrying the frame's `id`:
 `success: true` means the answer resolved a pending request. A refusal carries the same `id` and an
 `error`: on a host `question_incomplete` (a `question` answer with neither answers nor a comment),
 `question_already_resolved` (a late answer) or `unknown_extension_ui_request` (no request of that
-session has that id); on a terminal `unknown_request` or `invalid_response`. A single-session stdio
+session has that id); on a terminal `unknown_request`, `question_incomplete` or `invalid_response`. A single-session stdio
 connection answers every response it resolves the same way, and ignores one that matches none of its
 requests. A client may still fire and forget: the reply is an ordinary `response` record.
 

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@code-yeongyu/senpi",
-	"version": "2026.9.29-5",
+	"version": "2026.9.30",
 	"description": "Coding agent CLI with read, bash, edit, write tools and session management",
 	"type": "module",
 	"piConfig": {
@@ -56,9 +56,9 @@
 	},
 	"dependencies": {
 		"@earendil-works/chord": "0.85.1",
-		"@earendil-works/pi-agent-core": "npm:@code-yeongyu/senpi-agent-core@2026.9.29-5",
-		"@earendil-works/pi-ai": "npm:@code-yeongyu/senpi-ai@2026.9.29-5",
-		"@earendil-works/pi-tui": "npm:@code-yeongyu/senpi-tui@2026.9.29-5",
+		"@earendil-works/pi-agent-core": "npm:@code-yeongyu/senpi-agent-core@2026.9.30",
+		"@earendil-works/pi-ai": "npm:@code-yeongyu/senpi-ai@2026.9.30",
+		"@earendil-works/pi-tui": "npm:@code-yeongyu/senpi-tui@2026.9.30",
 		"@silvia-odwyer/photon-node": "0.3.4",
 		"chalk": "6.0.0",
 		"cross-spawn": "7.0.6",
@@ -77,8 +77,8 @@
 		"yaml": "2.9.1",
 		"@anthropic-ai/claude-agent-sdk": "0.3.284",
 		"@anthropic-ai/sdk": "0.127.0",
-		"@code-yeongyu/senpi-codemode": "2026.9.29-5",
-		"@earendil-works/pi-pty": "npm:@code-yeongyu/senpi-pty@2026.9.29-5",
+		"@code-yeongyu/senpi-codemode": "2026.9.30",
+		"@earendil-works/pi-pty": "npm:@code-yeongyu/senpi-pty@2026.9.30",
 		"@modelcontextprotocol/sdk": "1.30.0",
 		"@mozilla/readability": "0.6.0",
 		"linkedom": "0.18.13",

package/dist/bundle/chunks/chunk-AWEAVBCR.js

@@ -1,2 +0,0 @@
-import { createRequire as __piCreateRequire } from "node:module"; const require = __piCreateRequire(import.meta.url); { const __piWorkerThreads = require("node:worker_threads"); if (typeof __piWorkerThreads.markAsUncloneable !== "function") { __piWorkerThreads.markAsUncloneable = () => {}; } }
-import{HOST_GENERATION_ENV,HOST_INSTANCE_ID_ENV}from"./chunk-CIRZTP7W.js";import{engineBuildIdentity}from"./chunk-AGVPQLIU.js";import{parseArgs,resolveSessionRuntime}from"./chunk-7CQX3QFV.js";import*as crypto from"node:crypto";var CUSTOM_UNSUPPORTED_CAPABILITY="custom_unsupported",EXTENSION_EVENTS_CAPABILITY="extension_events",AUTO_TITLE_SESSIONS_CAPABILITY="auto_title_sessions",MEDIA_PLACEHOLDERS_CAPABILITY="media_placeholders",QUESTION_CAPABILITY="question",RETAIN_ON_DISCONNECT_CAPABILITY="retain_on_disconnect",SESSION_CONTEXT_CAPABILITY="session_context",SESSION_KIND_CAPABILITY="session_kind",AUTO_TITLE_PER_SESSION_CAPABILITY="auto_title_per_session",WARM_CAPABILITY="warm",DURABLE_SESSION_ID_CAPABILITY="durable_session_id",PROMPT_SURFACE_CAPABILITY="prompt_surface",RPC_CLIENT_CAPABILITIES_ENV="SENPI_RPC_CLIENT_CAPABILITIES";function parseClientCapabilities(value){return value?value.split(",").map(part=>part.trim()).filter(part=>part.length>0):[]}var DEFAULT_CUSTOM_EXTENSION_LABEL="custom UI component";function buildCustomUnsupportedRequest(capabilities,extensionName){if(!capabilities?.includes(CUSTOM_UNSUPPORTED_CAPABILITY))return;let name=extensionName.trim()||DEFAULT_CUSTOM_EXTENSION_LABEL;return{type:"extension_ui_request",id:crypto.randomUUID(),method:"custom_unsupported",extensionName:name}}import{createHash,randomUUID as randomUUID2}from"node:crypto";import{resolve}from"node:path";var INSTANCE_ID=resolveInstanceId(process.env[HOST_INSTANCE_ID_ENV]);function resolveInstanceId(value){return value!==void 0&&value.trim()!==""?value:randomUUID2()}function hostInstanceId(){return INSTANCE_ID}var cachedProfile;function hostGeneration(env){let value=env[HOST_GENERATION_ENV];return value!==void 0&&/^\d+$/.test(value)?Number(value):0}function hostLaunchProfile(argv,cwd){let parsed=parseArgs([...argv],{grokNeoEnabled:!1}),core={extensions:[...new Set((parsed.extensions??[]).map(path=>resolve(cwd,path)))].sort(),multi_session:parsed.multiSession===!0,session_runtime:resolveSessionRuntime(parsed)},canonical=JSON.stringify({extensions:core.extensions,multi_session:core.multi_session,session_runtime:core.session_runtime});return{profile_id:createHash("sha256").update(canonical).digest("hex"),core}}function protocolIdentity(){cachedProfile??=hostLaunchProfile(process.argv.slice(2),process.cwd());let build=engineBuildIdentity();return{instanceId:INSTANCE_ID,generation:hostGeneration(process.env),engineVersion:build.text,engineOrdinal:build.ordinal,launch_profile:cachedProfile}}export{CUSTOM_UNSUPPORTED_CAPABILITY,EXTENSION_EVENTS_CAPABILITY,AUTO_TITLE_SESSIONS_CAPABILITY,MEDIA_PLACEHOLDERS_CAPABILITY,QUESTION_CAPABILITY,RETAIN_ON_DISCONNECT_CAPABILITY,SESSION_CONTEXT_CAPABILITY,SESSION_KIND_CAPABILITY,AUTO_TITLE_PER_SESSION_CAPABILITY,WARM_CAPABILITY,DURABLE_SESSION_ID_CAPABILITY,PROMPT_SURFACE_CAPABILITY,RPC_CLIENT_CAPABILITIES_ENV,parseClientCapabilities,DEFAULT_CUSTOM_EXTENSION_LABEL,buildCustomUnsupportedRequest,hostInstanceId,hostGeneration,hostLaunchProfile,protocolIdentity};