Observed during the first real cross-machine call (laptop → Mac mini over Tailscale, local wrangler dev relay with #413's route workaround applied).
The callee answers successfully and the caller never receives it.
What each side saw
Caller:
ringing...
agent working...
answered...
Call failed (connection_failed): Connection closed before a reply arrived.
Callee, same call_id, from ~/.agentcall/lines/claude/calls.log:
{"call_id":"f38e3e06-…","from":"laptop2","status":"ok","duration_ms":8779,
"reply":"The file `~/e2e-note.md` contains the rotation cadence string: **`SENTINEL-ORANGE-7734`** …"}So: the request leg worked, the agent ran, the answer was produced and audited ok, and the caller then sat until the socket closed. Reproduced on three consecutive calls.
The caller reached answered..., which means the status frame arrived — it is specifically the encrypted result that never lands.
Why this is filed as unconfirmed
It was seen only under a local relay with the routes entry commented out (#413's workaround). That is a non-standard configuration, and it is entirely possible the reply leg has its own origin check that the same route removal disturbs in the other direction.
Check it against the hosted relay before treating it as a product bug. If it reproduces there, it is serious — a caller cannot receive an answer the callee has already produced, spent tokens on, and logged as delivered. If it does not, this is a second symptom of #413 and should be closed into it.
What it does not affect
Nothing about #409's merge. The e2ee and call-client paths are untouched by that branch — git diff 6dbf1c6 HEAD -- packages/cli/src/call-client.ts packages/cli/src/e2ee.ts packages/shared/src is empty, and the only relay change was an unrelated asset route.
Related
#413 — the request-leg origin mismatch found in the same session
Observed during the first real cross-machine call (laptop → Mac mini over Tailscale, local
wrangler devrelay with #413's route workaround applied).The callee answers successfully and the caller never receives it.
What each side saw
Caller:
Callee, same
call_id, from~/.agentcall/lines/claude/calls.log:{"call_id":"f38e3e06-…","from":"laptop2","status":"ok","duration_ms":8779, "reply":"The file `~/e2e-note.md` contains the rotation cadence string: **`SENTINEL-ORANGE-7734`** …"}So: the request leg worked, the agent ran, the answer was produced and audited
ok, and the caller then sat until the socket closed. Reproduced on three consecutive calls.The caller reached
answered..., which means the status frame arrived — it is specifically the encrypted result that never lands.Why this is filed as unconfirmed
It was seen only under a local relay with the
routesentry commented out (#413's workaround). That is a non-standard configuration, and it is entirely possible the reply leg has its own origin check that the same route removal disturbs in the other direction.Check it against the hosted relay before treating it as a product bug. If it reproduces there, it is serious — a caller cannot receive an answer the callee has already produced, spent tokens on, and logged as delivered. If it does not, this is a second symptom of #413 and should be closed into it.
What it does not affect
Nothing about #409's merge. The e2ee and call-client paths are untouched by that branch —
git diff 6dbf1c6 HEAD -- packages/cli/src/call-client.ts packages/cli/src/e2ee.ts packages/shared/srcis empty, and the only relay change was an unrelated asset route.Related
#413 — the request-leg origin mismatch found in the same session