[bug] A coding session relocated to another machine silently starts with an empty conversation — the resume pointer is a file on the machine it left

[serge-ivo]

A coding session can legitimately move to a different machine while staying active. Its resume pointer cannot move with it, because the pointer is a file on the machine it left.

The two halves that disagree

The cloud half — relocation is one D1 column. lib/coding-store.ts:550:

export async function reassignSessionNode(env: Env, instanceId: string, userId: string, sessionId: string, runnerNode: string | null): Promise<void> {
	await env.DB.prepare(
		"UPDATE coding_sessions SET runner_node = ?4, updated_at = datetime('now') WHERE id = ?1 AND instance_id = ?2 AND user_id = ?3",
	)

The session keeps its id and its status. lib/coding-session-lifecycle.ts:59 is explicit that this is intended: "reassignSessionNode leaves the status alone, so a session legitimately relocated to a live machine can sit suspended. Treating it as a stop would end a healthy run at step 0."

The runner half — the pointer is local. coding/headless.ts:266:

this.claudeSessionId = readState(config.statePath, config.id) ?? (config.resumeFrom ? readState(config.statePath, config.resumeFrom) : null);

readState (:938) reads loadFile(path)[id] from statePath, set to defaultStatePath(this.reposBaseDir) (coding/runtime.ts:238) — a JSON file on that runner's own disk. It maps our session id to Claude Code's session id, and the conversation behind it lives in ~/.claude on that same machine.

The failure

Session relocates from machine A to machine B. On B, readState(statePath, config.id) finds no entry — B's state file never had one. resumeFrom does not help: it is looked up in the same local file. buildClaudeArgs therefore appends no --resume (:888 — if (resumeId) args.push("--resume", resumeId)), and the engine starts with an empty conversation.

Nothing reports this. The session row still says active, the id is unchanged, and the console shows a live session. The user is mid-piece-of-work and the agent has quietly forgotten everything.

It is the exact failure #408 was written to prevent — its module header calls out that the pre-#408 behaviour was "reap, then re-open → always fresh, silently" — reached by a different route that #408 did not cover. resolveSessionContinuity never runs on this path at all: relocation is not an open.

Verified vs inferred — read this before estimating

Verified by reading the code: the SQL above touches one column; statePath resolves to a local path with no sync anywhere (grep -n statePath packages/browser-runner/src/coding/*.ts returns 5 hits, all local reads/writes in headless.ts and runtime.ts); --resume is appended only when the local lookup returns a value.

NOT reproduced. I have not run a two-machine relocation and watched the conversation drop. That test is available and cheap — the account has two known machines (Sergeys-Mac-mini.local, RLs-MacBook-Air.local) and instance bd43f4de is pinned to the mini. Someone should run it before this is closed, because the whole finding rests on "nothing copies the file", which is an absence.

Fix

Two options, and the second is the real one:

1. Narrow: when relocating, either carry the resume mapping or explicitly mark the session as having lost continuity, so the loss is at minimum reported rather than silent. This is a patch on a design that will keep producing this class.
2. Structural: [design] The platform owns the conversation — an engine's own memory is an optimisation, not the source of truth #693 — if the conversation lives in coding_timeline rather than in a file on one laptop, relocation is not a special case at all. A session moves machines and the brief travels with it, because the brief is in D1.

Prefer 2. File 1 only if 2 is not being taken soon, since a silent wrong answer is worse than a slow one.

[serge-ivo]

Dissolved by #693's slice 1 — e82da9b0. Leaving open, for one reason: the finding was never reproduced.

This issue asked for option 2 ("structural — if the conversation lives in coding_timeline, relocation is not a special case at all") and preferred it over the narrow patch. That is what shipped, and it reaches this path specifically rather than incidentally.

What changed on this exact path

The brief is attached in startSessionOnRunner, not at the two open paths — and this issue is the reason. Relocation is not an open: reassignSessionNode is called from the re-attach branch, which has no continuity object at all, so anything hung off the continuity decision would have missed it. startSessionOnRunner is the cloud's only caller of /coding/start, so the brief now rides on every launch including this one, and it is composed after the relocation so it is read for the session's new home rather than for the machine it left.

The runner spends it only when the engine came up with no conversation of its own — which on machine B is exactly what happens, for the reason this issue traced: readState(statePath, config.id) finds no entry, and resumeFrom does not help because it is looked up in the same local file.

So the two halves that disagreed now agree, without the pointer moving. The pointer still cannot move; the record was already in D1 and is now read back.

And it is no longer silent. That was the other half of the title. The console banner, the chat notice and the MCP reply all report a briefed engine, in the ADR's wording — reconstruction, never memory.

The guard

coding-session-open.test.ts, "briefs a session RELOCATED to another machine — the case the ADR was written about (#694)": drives the reclaim (relayConnected false, a live fallback on another node), asserts reassignSessionNode was called and that the /coding/start body carries a non-empty brief. Watched failing with the wiring removed. This is also ADR 0005's enforcement clause 2, which names relocation as "the known hole" and asks for exactly this test.

Why it stays open

The issue says, in its own words: "NOT reproduced. … Someone should run it before this is closed, because the whole finding rests on 'nothing copies the file', which is an absence."

That is still true, and it is still the right bar. I did not run a two-machine relocation, and I must not drive the account's machines. What the code now does on that path is pinned by a test; what a real engine does after being relocated and briefed has not been watched by anyone.

The reproduction that would close this is the one the issue already specified — the account's two known machines and instance bd43f4de, pinned to the mini:

1. npm i -g @proagentstore/cli on both machines (the runner half needs 0.4.57; an older pags up drops the seed field and behaves exactly as it does today).
2. Start work on a repo on the mini and give it something specific to remember.
3. Stop that runner, pags up on the Air, and drive the same session.
4. Ask it what you were doing.

Before this change the expected answer was nothing, silently. Now it should describe the work and say it was told rather than that it remembers. If it claims memory, that is a defect in the wording and worth filing — the ADR is explicit that the claim must never be "as if it never died".

[serge-ivo]

Auditing the closing comment: the engine half holds, the reporting half does not. Filed as #738.

And it is no longer silent. … The console banner, the chat notice and the MCP reply all report a briefed engine

Verified that a relocated engine really is briefed — startSessionOnRunner composes after reassignSessionNode, unconditionally. But all three surfaces are unreachable on that path:

• open-notice.ts:69 returns null on !continuity before the seeded branch — and this path, as coding-session-open.ts's own header says, "has no continuity object at all";
• coding-session-open.ts:555 returns notice: null whenever !ensured.opened, which is the re-attach branch that e82da9b0 deliberately added seeded to;
• six of the eight startSessionOnRunner call sites — including /sessions/:id/start, the reuse and create-race arms of POST /sessions, /restart, and the /message machine-switch retry that is the primary relocation trigger — never put seeded in a response at all. The two that do are the two where relocation cannot occur.

Practical consequence for the reproduction this issue is still open for: if it is run and the engine answers well, the banner will be absent anyway. That should be read as #738, not as the reproduction failing.

[serge-ivo]

Audit verdict: PARTIAL — the code is complete on both halves of the title now; what remains is the reproduction this issue itself set as the bar.

Re-verified at e1238788:

• The engine half — startSessionOnRunner composes the brief unconditionally after reassignSessionNode, so a relocated engine comes up briefed. workers/api/src/lib/coding-session-open.ts:225 records the ordering in place: "Read AFTER the relocation above, so a session that just moved machines is briefed from the …". Guarded by coding-session-open.test.ts under the [bug] A coding session relocated to another machine silently starts with an empty conversation — the resume pointer is a file on the machine it left #694 name.
• The reporting half — this was the gap the 2026-08-22 audit found and filed as A relocated session is briefed and still reports nothing: the console banner returns null before it reads seeded, and six of eight launch call sites never send it #738, and A relocated session is briefed and still reports nothing: the console banner returns null before it reads seeded, and six of eight launch call sites never send it #738 shipped in 3fd4e8d4 and is now closed. The banner (open-notice.ts:74-113, seeded checked above the continuity guard), the chat notice (coding-session-open.ts:625, narrowed to !ensured.opened && ensured.seeded !== true), all four remaining response bodies (routes/coding.ts:158, 197, 231, 805) and the MCP reply all report a briefed engine. The warning I carried on that comment — "if the reproduction is run and the engine answers well, the banner will be absent anyway" — no longer applies.
• A durable trace now exists too, which it did not when this issue was written: relocationNote (coding-session-open.ts:146-152) writes a system row into coding_timeline naming both machines and which of the three outcomes occurred. A banner needs someone looking; this does not.

What remains — one reproduction, and it is the bar this issue set for itself

NOT reproduced. … Someone should run it before this is closed, because the whole finding rests on "nothing copies the file", which is an absence.

That still stands and it is still right. I did not run a two-machine relocation and I must not drive the account's machines.

Preconditions, checked today so the run is not wasted:

• The runner half needs @proagentstore/cli ≥ 0.4.57. GET /v1/instances/a185b1db-…/coding/diagnostics reports runnerVersion: "0.4.57" on RLs-MacBook-Air.local. The mini has not been checked — install there too before starting, or an older pags up drops the seed field and the run measures nothing.
• Instance bd43f4de-… (ChessClubs App Coder) is still active but its runner is currently status: "registered", reachable: false — i.e. offline. That is fine for the test (it is the "machine A went away" half) but it means the run starts on whichever machine is up.

The run: start work on a repo on one machine and give it something specific to remember → stop that runner → pags up on the other → drive the same session → ask what you were doing.

What to expect now, and it differs from the last time this was written: the engine should describe the work and say it was told rather than that it remembers, the console should show the warn-tinted "Started a fresh conversation… It was given a brief…" banner, and GET …/coding/repos/:repoId/timeline should hold a system row reading "Moved to — was no longer connected. A new engine started there with no conversation of its own, and was given a brief…".

If it claims memory, that is a wording defect and worth filing — ADR 0005 is explicit that the claim must never be "as if it never died". If the banner is absent, that is now a real regression rather than #738.