[fylorn]

OpenAI Responses with store: false (how Codex always sends) hands the client encrypted state to send back every turn: reasoning, remote compaction, and Codex multi-agent messages (agent_message content parts of type encrypted_content). Only the account that encrypted it can read it. When a conversation moved to another upstream — the route changed, a load-balance group rotated after the cache went cold, or a failover — every following request failed with invalid_encrypted_content ("Encrypted function output content could not be decrypted or decoded"), often as an error event inside a 200 stream. Dropping encrypted reasoning (seal.rs) does not help when the encrypted part is the sub-agent's message itself.

What changes

• tw_dialect::sealed (shared with the enterprise gateway): sealed(body) tells whether a Responses request carries upstream-encrypted content, and whether it is only reasoning (Sealed::Reasoning) or something that cannot be dropped (Sealed::Content). Values the gateway wrote itself (tw1. prefix) do not count. refused(wire, said) recognises an upstream refusing such content; seal::refusal now uses it and also matches the "could not be decrypted or decoded" wording.
• Affinity remembers, per conversation, the upstream that last answered it (holder). Unlike the cache-driven stay, it survives the upstream going quiet, group changes, cache expiry and config reloads, and conversations that carried encrypted content are kept for 30 days instead of one.
• Routing: a request carrying encrypted content goes back to its holder whatever the rule picks now (Stay::Sealed in the routing view).
  • Content: the holder is the only candidate, no failover. If it was removed from the config, the request is refused up front with gw.route.sealed_upstream_gone.
  • Reasoning only: the holder goes first; other candidates stay as failover, where seal.rs drops the reasoning they cannot read.
  • Unknown holder (after a restart): routed as before.
• Failure message: when an upstream refuses encrypted content, in a 4xx body or an error event mid-stream, the request fails with gw.upstream.sealed_elsewhere, which says another upstream encrypted the history and what to do, followed by the upstream's own words.
• Docs: config.md / config.zh-CN.md describe the behaviour next to conversation affinity.

New message codes: gw.route.sealed_upstream_gone, gw.upstream.sealed_elsewhere. New Stay value: sealed. No protocol bump: older UIs show the English text and no stay label.

Tests

• tw-gateway/tests/sealed.rs drives the real pipeline against two fake accounts that each refuse the other's encrypted content: a sealed conversation returns to its account after a config change and does not fail over; a removed holder is refused plainly; reasoning-only prefers its account and still fails over; both refusal shapes (400 and in-stream) produce the new message. Three of the four fail with the pin disabled.
• Unit tests for detection, refusal recognition and holder retention.
• cargo fmt --check, cargo clippy --workspace --all-targets -D warnings, cargo test --workspace pass locally.

🤖 Generated with Claude Code