The Second Connection Was Still the First

The Codex run had succeeded. The Work Room showed the same provider session, the follow-up returned the exact confirmation string, and the parent transcript contained both completed cards. Then we reloaded the page and the Host said:

already authenticated: open a new connection

That answer sounded reasonable. The browser had opened a new WebSocket. The surprise was that, from the Host's point of view, it had not opened a new connection at all.

OIP sessions commonly travel through the relay. The relay multiplexes browser traffic to a Host using the application session ID. On reload, the new browser socket can send its signed CONNECT before the close from the old socket has been delivered and processed. Both frames briefly occupy the same logical relay queue. The second physical connection therefore arrives inside the first run_ws_session loop, where the connection is already authenticated.

The existing rule rejected every second CONNECT. It was added for a good reason: an authenticated socket must not replace its caller, downgrade signed commands, point at another recipient, or switch sessions. Removing that guard would fix reload by reopening a security boundary.

The useful distinction was not first versus second. It was change versus reattach.

A reload now gets one narrow path. The Host verifies the fresh signature again, then requires the same caller, recipient, signed-command capability, supported OIP protocol, and application session. If all of those are equal, it republishes CONNECTED and the authenticated profile. It does not start a second forwarder for a running agent. If any field differs, the old rejection remains. Reusing the same signature still fails the replay guard.

The first public alpha taught us that “verifies the fresh signature again” was still too broad. The implementation reused the whole first-connect gate, so it also repeated the mutable trust decision: read the contact lists, decide whether the caller must onboard, and consult policy. A brand-new session connected, but its first Send raced another equivalent CONNECT through that second policy read. A local missing-file error became misconfigured: [Errno 2] in the browser, and the actual INPUT never reached the Host.

That was not a reason to weaken reauthentication. It was a reason to name its two halves. A first connection proves the signed identity and authorizes it under current policy. An equivalent reattach must prove the signed identity, recipient, freshness, replay claim and current blacklist again, then show that every bound connection field is unchanged. It must not ask onboarding/contact policy to authorize the same still-live connection twice, nor re-read admin lists and rebuild permission authority that connection already owns. It republishes the existing mode, profile, transcript, and dashboard state to the new physical browser socket. Custom verifiers retain their existing gate unless they explicitly provide the same narrow reattach half.

The tests make the boundary visible. One session-loop test puts two freshly signed, equivalent CONNECT frames into the same logical stream and expects two CONNECTED replies for the same session. Six negative cases try to change the identity, recipient, capability, session, protocol, or reuse a signature. Every one is rejected. A regression makes trust policy raise the exact missing-file error and proves reattach never calls it; another makes admin/mode initialization raise the same error and proves it is not repeated. A newly blacklisted caller is still refused. Together with the existing Host, relay, replay, profile, and command-signing coverage, 76 focused tests passed in the follow-up run.

The production screenshot was the important measurement. Before this change, the transcript proved that Codex had finished while a red authentication error claimed the page was broken. That contradiction exposed two different bugs: O Chat held on to a cleared error, and the Host created a new error during reload. Fixing only the banner would have made the first screenshot cleaner and the next refresh fail again.

Connection identity is a stack of names: physical WebSocket, relay route, authenticated caller, OIP application session, and provider session. In the simple case they begin and end together, so it is tempting to treat them as one thing. Reload is where they separate. The browser connection can be new while the relay route and application session are deliberately old. A correct reconnect policy preserves that continuity without letting any authority move.

The lesson is small enough to reuse: idempotence is not the absence of a security check. It is the security check that proves nothing changed.