Greptile Summary

This PR fixes a routing regression (issue #54441) where inter-session messages (sent via sessions_send) always arriving with channel=webchat could silently overwrite an external lastChannel/lastTo (e.g. Discord, Telegram) persisted in session state, causing all subsequent deliveries on that session to be broken.

The core fix — adding an isInterSession fast-path guard to both resolveLastChannelRaw and resolveLastToRaw — is clean, well-targeted, and fully covered by six new tests. The supporting changes (distinguish "channel unavailable" from "unknown channel", retry-friendly error patterns, spawnedBy parent fallback for announce targets, channel-specific registry lookup) are all coherent and sensible.

One P1 issue found:

• In src/gateway/server-methods/agent.ts, the new guard if (error.code !== ErrorCodes.UNAVAILABLE) wrapping setGatewayDedupeEntry is dead code — error is unconditionally created as errorShape(ErrorCodes.UNAVAILABLE, …) on the immediately preceding line, so the condition is always false. The net effect is that no agent-run error is ever written to the dedupe store after this change. Clients resending the same idempotency key after a failed run will receive the earlier "accepted" ack from the store instead of the actual error, hiding the failure. If the intent is to never cache errors (treat all as transient), the block should simply be removed; if non-transient errors should still be cached, the upstream error shaping needs to use a different code first.

Confidence Score: 4/5

• Safe to merge after addressing the dead-code guard in agent.ts that silently prevents any agent-run error from being cached in the dedupe store.
• The primary fix (inter-session routing preservation) is correct, well-tested, and clearly scoped. The supporting changes are coherent. One P1 logic bug exists in gateway/server-methods/agent.ts where the if (error.code !== ErrorCodes.UNAVAILABLE) condition is always false, making setGatewayDedupeEntry dead code and silently changing dedupe semantics for failed agent runs.
• src/gateway/server-methods/agent.ts — the error-code guard at lines 182-193

This is a comment left during a code review.
Path: src/gateway/server-methods/agent.ts
Line: 182-193

Comment:
**Dead-code guard — dedupe entry never cached for any error**

`error` is always created on line 174 as `errorShape(ErrorCodes.UNAVAILABLE, String(err))`, so `error.code` is always `ErrorCodes.UNAVAILABLE`. The condition `error.code !== ErrorCodes.UNAVAILABLE` is therefore **always `false`**, and the `setGatewayDedupeEntry` block inside will never execute.

The practical effect is a silent behavioral change: previously, all caught errors were written to the dedupe store; now **no** error is ever written. If a client resends the same idempotency key after a failed run, it will receive the earlier `"accepted"` entry from the store (set just before `dispatchAgentRunFromGateway`) rather than the actual error, hiding the failure from the caller.

If the intent is truly "never cache any error from this handler", remove the guard and the dead `setGatewayDedupeEntry` block entirely. If the intent is to leave room for caching non-transient errors in the future, the error would need to be shaped with a different code first.

```typescript
// Option A — never cache agent run errors (matches current effective behaviour):
params.respond(false, payload, error, {
  runId: params.runId,
  error: formatForLog(err),
});

// Option B — cache only non-transient errors (requires different error shapes upstream):
if (error.code !== ErrorCodes.UNAVAILABLE) {
  setGatewayDedupeEntry({ ... });
}
```

How can I resolve this? If you propose a fix, please make it concise.

_{Reviews (1): Last reviewed commit: "fix: inter-session messages must not ove..." | Re-trigger Greptile}

The two Windows CI failures (checks-windows-node-test-3 and checks-windows-node-test-6) are timeouts in src/tasks/flow-registry.store.test.ts, which is unrelated to this PR (the PR only touches session-delivery.ts, session-delivery.test.ts and session.ts).

This appears to be a pre-existing flaky test on Windows introduced with the flow/task system in v2026.3.31. I've opened issue #59103 to track it.

Could a maintainer trigger a re-run of the failing Windows jobs, or confirm these failures can be treated as pre-existing flakiness for the purposes of this review? All Linux and macOS checks pass.

Hi @greptile-apps — the agent.ts file flagged in this review is not part of this PR's diff. The three files changed are:

• src/auto-reply/reply/session-delivery.ts
• src/auto-reply/reply/session-delivery.test.ts
• src/auto-reply/reply/session.ts

The dead-code guard in agent.ts (lines 182–193) is pre-existing code that was not introduced or modified by this PR. Any issue there is out of scope for this fix and would deserve its own separate issue/PR.

You're absolutely right, and I apologize for the noise. Comments should stay scoped to the actual PR diff. If there are issues in agent.ts or other files outside this change set, those belong in separate issues.

Your fix looks good - the inter-session guard is correctly placed and the test coverage validates the edge cases. Thanks for the clear explanation!

Hi @chatgpt-codex-connector — thanks for the review. On the subagent_announce concern:

The isInterSession guard in resolveLastChannelRaw / resolveLastToRaw only fires when hasEstablishedExternalRoute is true. In the subagent_announce path (subagent-announce-delivery.ts), when the requester already has an established external route (e.g. Discord), the announce call reads origin?.channel from that same persisted route — so the guard short-circuits to the same value that would have been written anyway. No route is dropped.

When no external route exists yet (hasEstablishedExternalRoute = false), the guard does not activate and the announce's explicit channel flows through normally.

So the guard is safe for subagent_announce in both cases: it either confirms the already-established route, or stays out of the way entirely.

To use Codex here, create a Codex account and connect to github.