[bug] No MCP tool can open a resuming session — the only opener hardcodes fresh:true, so #408's continuity is console-only

[serge-ivo]

resolveSessionContinuity (#408) makes a re-opened session continue the repo's conversation for four days. Over MCP that is unreachable: the only tool that can open a session hardcodes the flag that turns it off.

The three coding-session tools, and why none of them can do it

coding_session_fresh — opens, but forces cold. workers/mcp/src/index.ts:1051:

const d = await authedCall(`/v1/instances/${instance_id}/coding/sessions`, sessionToken, { method: "POST", body: JSON.stringify({ repoId, engineId: engine_id || "claude", fresh: true }) }, this.env);

fresh: true reaches lib/coding-session-open.ts:227:

if (opts?.forceFresh) return resolveSessionContinuity({ engine, previous: null, forceFresh: true });

which returns mode: "fresh", resumeFrom: null, reason "you asked for a clean slate". The tool is doing exactly what its description promises ("clean state, no --resume") — it is the right tool, and it is the only one.

coding_session_message — requires an already-active session. index.ts:915-917:

const r = (await authedCall(`/v1/instances/${instance_id}/coding/sessions`, sessionToken, {}, this.env)) as { sessions?: Array<{ id: string; status: string }> };
const sid = session_id || sessions.find((s) => s.status === "active")?.id;
if (!sid) return text("No active coding session found.");

It GETs the list and looks for status === "active". It does not open one.

coding_session_restart — same lookup, same dead end (index.ts:940-944).

Confirmed empirically 2026-08-17 against instance bd43f4de with its previous session reaped: coding_session_message returned "No active coding session found."

grep -c 'coding/sessions, sessionToken, { method: "POST"' workers/mcp/src/index.ts→ **1**, and that one iscoding_session_fresh`. There is no other door.

Why this matters more than a missing tool usually does

The console reaches the resuming path (routes/coding.ts:202, lib/coding-session-open.ts:333, both passing continuity.resumeFrom into startSessionOnRunner). MCP is the surface an owner uses to check on and continue work from somewhere other than the console — which is the exact scenario #408 exists for. So the capability is built, tested, and shipped, and is available from precisely one of its two entry points.

Working around it required calling POST /v1/instances/:id/coding/sessions directly with a token lifted from the CLI's own ~/.config/proagentstore/session.json. That is not a workflow to document; it is evidence the tool is missing.

Fix

Small: expose the create call without fresh: true. Either

• a new coding_session_open (instance_id, repo_id?, engine_id?) that POSTs without the flag and returns the continuity block the route already sends back, or
• an optional fresh boolean on coding_session_fresh, defaulting false, and rename it — though a tool whose name says "fresh" defaulting to "not fresh" is worse than a second tool.

Prefer the first. Return continuity.reason verbatim in the tool's text output so a caller can say which conversation it got — the route already computes it and #697 covers the console side of the same omission.

Also worth doing while here: coding_session_message should be able to wake a sleeping repo rather than refusing. "No active coding session found" is the MCP-side spelling of the same leak filed in #695 — the caller asked to talk to an agent and got told about our process lifecycle. Once an open-with-continuity tool exists, message should fall back to it instead of erroring.

Surface-lock note: adding a tool name bumps MCP_SERVER_VERSION and appends a SURFACE_LOCK entry (see workers/mcp/src/server-version.ts and surface-lock.ts), plus the counts in tool-count.ts and tool-metadata.ts. pnpm docs:drift names the doc claims that restate them.

[serge-ivo]

Shipped in 5fcc5adf. CI green; Deploy MCP Worker, Deploy Host Worker and Publish MCP Registry all succeeded.

Verified live:

$ curl -sS https://mcp.proagentstore.online/health
{"ok":true,"service":"proagentstore-mcp","tools":142}     # was 141

$ curl -sS https://proagentstore.online/.well-known/mcp-server.json
"version": "0.1.11"

The tool. New coding_session_open (instance_id, repo_id?, engine_id?), scope runtime, surface-gated to coding. POSTs /v1/instances/:id/coding/sessions without fresh, so resolveSessionContinuity runs its real policy, and returns continuity.reason verbatim. It reports a resume decision the runner did not confirm (resumed !== true) as a decision rather than an outcome, and omits engineId when the caller names none so the API uses the instance default instead of coding_session_fresh's hardcoded "claude" (#549).

The defaulting-fresh-boolean alternative was rejected, as the issue directs, and the rejection is recorded in the commit body.

coding_session_message now wakes a sleeping repo through that path instead of answering "No active coding session found." Ambiguity is handled honestly rather than guessed: 0 repos → "no repo attached, add one with coding_repo_add"; >1 idle repos → names each with its repo_id and opens nothing.

Two numbers differed from what I briefed, and reality won both times:

• Always-on stays 122. The coding tools sit inside if (groups.has("coding")), so the new opener is surface-gated, not always-on. index.test.ts drives the real registration path with every surface on and with none, and confirms 142 / 122. Gated 19 → 20; MCP_RISK_COUNTS.runtime 15 → 16.
• The version is 0.1.11, not 0.1.10. MCP token parameter contract: audit findings #681 landed 0.1.10 while this was being written, so the entry is appended below it — the same collision the 0.1.10 comment itself records, one issue apart, and precisely why the map is append-only rather than renumbered. The fingerprint was recomputed after the rebase, not carried over: MCP token parameter contract: audit findings #681's new token argument is inside inputSchema and therefore inside the hash, so the pre-rebase value described a surface that never existed on main. Recorded hash sha256:5b9c234f…, computed by conformance.test.ts against the shipped tree, in the same commit as the entry.

File-size ratchet: extracted, not raised. index.ts was one line under its pin, so the ten coding registrations moved verbatim to a new workers/mcp/src/coding-tools.ts (where the eleventh joined them); index.ts is now 933 and its pin came down.

pnpm docs:drift named the count restatements and all were updated (platform-docs/mcp.md, workers/mcp/{README,CLAUDE,AGENTS}.md, server.json, store/.well-known/mcp-server.json, store/about/index.html, store/llms-full.txt, docs/mcp-instance-runtime.md). workers/mcp/CLAUDE.md's hand-maintained per-file sum was found stale beyond the bump (it read 31 + 13 + 93 = 140 under a headline of 141, and instance-tools/ registers 97, not 93) and was re-counted.

Verified: pnpm typecheck, pnpm vitest run (551 files / 9579 tests, three consecutive clean runs), biome, all nine script gates incl. check-surface-lock --require-history and check-mcp-parity, docs:drift, docs:build, console build, workers/mcp tsconfig.test.json, and pnpm test:e2e 423/423 (chromium + webkit) since store/ docs changed.

Not verified live: calling the tool end-to-end needs an OAuth session and a machine running pags up. /health reporting 142 and the registry serving 0.1.11 is the deployed evidence.