Fix: CONNECT tunnel-open events mis-attributed to wrong session when multiple agents run concurrently

[msteinder]

Summary

When two coding agents run simultaneously (e.g. OpenCode + Codex CLI, both routing through Cortex), CONNECT tunnel-open events from one agent's session appear in the other agent's session timeline in abctl observe. The mis-attribution only affects the opaque tunnel-open row; TLS-bridged (decrypted) inner requests are attributed correctly.

Sample

The following abctl session timeline shows an OpenCode session (rows 383, 386) interleaved with what appears to be unrelated traffic (rows 384, 385). Rows 383 and 386 are inference calls to a local LiteLLM endpoint. Row 384 is a firmware update CDN tunnel. Row 385 — a chatgpt.com GET — is a model-discovery request from a concurrently running Codex CLI process, but it was recorded under this OpenCode session ID.

 383   16:06:18.47   out   req      observe   rits/zai-org/glm-…                                 213,792  litellm.cb.ete.res.…
 384   16:06:46.02   out   req      tunnel                                                                cdn.fwupd.org:443
 383   16:08:00.86   out   resp     observe   rits/zai-org/glm-…  200         102.45s              7,175  litellm.cb.ete.res.…
 385   16:10:18.87   out   req      —                                                                     chatgpt.com
 385   16:10:19.35   out   resp     —                             200           481ms                     chatgpt.com
 386   16:10:33.66   out   req      observe   rits/zai-org/glm-…                                 221,075  litellm.cb.ete.res.…
 386   16:11:03.15   out   resp     observe   rits/zai-org/glm-…  200          29.57s              1,963  litellm.cb.ete.res.…

The JSON event logged by Cortex confirms the session ID:

{
  "at": "2026-09-29T14:49:07.990883-04:00",
  "client": {
    "raw": "codex-tui/0.159.0 (Mac OS 15.7.7; arm64) Apple_Terminal/455.1 (codex-tui; 0.158.0)"
  },
  "direction": "outbound",
  "host": "chatgpt.com",
  "httpMethod": "GET",
  "httpPath": "/backend-api/codex/models",
  "invocations": {
    "outbound": [
      {
        "action": "skip",
        "path": "/backend-api/codex/models",
        "phase": "request",
        "plugin": "tool-prune",
        "reason": "path_not_inference"
      }
    ]
  },
  "phase": "request",
  "requestId": "3ob-388c1a",
  "seq": 650,
  "sessionId": "ses_f122e67c3ffeJGjewfuKatYTyd"
}

The client.raw field identifies this as Codex CLI (codex-tui/0.159.0), but sessionId is the OpenCode session. The two processes were running simultaneously.

Root Cause

recordTunnelOpened in core/listener/forwardproxy/transparent.go:194 always resolves the session by calling s.Sessions.ActiveSession() — the globally most-recently-updated session — rather than using the session ID that handleConnect already resolved correctly from the CONNECT request headers:

// transparent.go:190
func (s *Server) recordTunnelOpened(pctx *pipeline.Context, reason pipeline.TunnelReason) {
    if s.Sessions == nil {
        return
    }
    sid := s.Sessions.ActiveSession()   // ← always the global "last writer wins" ID
    if sid == "" {
        sid = session.DefaultSessionID
    }
    // ...
    s.Sessions.Append(sid, ev)
}

The call chain is:

1. handleConnect (server.go:1297) receives the CONNECT request.
2. resolvePluginSessionID(r.Header) (server.go:1348) correctly reads X-Claude-Code-Session-Id → pins a local sessionID.
3. tunnelRecorderFor(pctx, skipped) (server.go:1860) returns a closure.
4. That closure calls s.recordTunnelOpened(pctx, reason).
5. recordTunnelOpened ignores pctx for session resolution and calls ActiveSession() instead.

The race: if OpenCode's inference response landed last, ActiveSession() returns OpenCode's ID at the moment Codex's CONNECT tunnel opens → Codex's chatgpt.com event is appended to OpenCode's session.

This is distinct from the fix in #984, which corrected session attribution for HTTP requests through resolvePluginSessionID / serveOutbound. The tunnel-open recording path was not updated at the same time.

Note that TLS-bridged inner requests are not affected: bridgeServe → serveOutbound re-reads the session header from the decrypted inner request (server.go:764), so decrypted rows are attributed correctly. Only the opaque CONNECT tunnel-open event itself is mis-attributed.

Suggested Fix

Pass the pinned sessionID from handleConnect through to recordTunnelOpened instead of re-calling ActiveSession(). The session ID is already available on pctx at the point tunnelRecorderFor is called (line 1425), so one approach is to store it on pctx before handing the context to tunnelRecorderFor, then read it back in recordTunnelOpened:

// recordTunnelOpened: use pctx's session ID instead of ActiveSession()
sid := pctx.OutboundSessionID   // already set by handleConnect at server.go:1349
if sid == "" {
    sid = s.Sessions.ActiveSession()   // keep as fallback for transparent-proxy path
}
if sid == "" {
    sid = session.DefaultSessionID
}

The transparent-proxy path (HandleTransparentConn) passes nil headers and has no CONNECT request to read from, so ActiveSession() remains the correct fallback there.

Environment

• OS: Darwin arm64
• Agents running concurrently: OpenCode (LiteLLM endpoint) + Codex CLI 0.159.0
• Affected path: opaque CONNECT tunnel-open events only (non-bridged traffic)

[huang195]

Investigation (against main @ d28b588)

Short version: the bug described here is real, but it is a narrow case. The sample in the issue was caused by something else, and the suggested fix leaves the sample rows unchanged.

The sample row is not a tunnel-open event

The logged JSON has httpMethod: GET, httpPath: /backend-api/codex/models, a tool-prune invocation, and no tunnel: true. recordTunnelOpened always writes CONNECT, an empty path and Tunnel: true, so it cannot have written this row.

The row came from serveOutbound recording the decrypted inner request. That request carries no header from session.id_headers. resolvePluginSessionID therefore fell back to ActiveSession(), which is the session that recorded anything most recently, across the whole store. That was the OpenCode session. Row 384 (the fwupd tunnel) got its session the same way.

Two corrections to the analysis above:

• TLS-bridged inner requests are affected. They are attributed by their header when they have one, and by ActiveSession() when they don't. The sample is one of the second kind.
• handleConnect never sets pctx.OutboundSessionID. Line 1349 sets pctx.Session.

Reproduction

I wrote a throwaway test that sends a real CONNECT through the TLS bridge. Session A, standing in for OpenCode, is the most recent writer when each case runs.

Case	Today	With the suggested fix
H1: bridged request, no session header anywhere (the sample)	tunnel row and GET both filed in A	unchanged
H2: CONNECT has no header, inner request has header B	tunnel row in A, request in B. The other session gets a stray tunnel row, and abctl can't fold that row into its request, because the fold only works within one session.	unchanged
H3: the CONNECT itself carries header B	tunnel row in A	fixed (B)

The suggested fix only helps H3, and in practice clients don't put session headers on a CONNECT. For a CONNECT without a header, the id handleConnect resolves is also ActiveSession(), just read a few milliseconds earlier.

H3 is still a real gap. It was left open by the one-identity fix in 220b5e4: denials and plugin identity use the id resolved when the CONNECT is gated, but the allowed tunnel row re-reads ActiveSession() at transparent.go:194. The comment at transparent.go:112–119 says this re-read doesn't happen.

Root cause

Session ids only arrive as headers on an agent's own API requests. Everything else carries none, so all of it is filed by ActiveSession():

• CONNECTs
• MCP calls
• WebFetch
• the gh/git/curl an agent's shell runs
• an agent's start-up calls

With one session at a time that guess is usually right. With two at once, the traffic goes into whichever session last recorded something.

I sampled about 450 CONNECT rows across 8 sessions on a laptop running several Claude Code sessions plus Bob:

• About 84% open a connection whose decrypted requests do carry the session header (inference calls). The proxy can attribute these on its own.
• The rest cannot be attributed from the traffic alone. These are connections to an MCP server, gh, git, curl, WebFetch and Bob. Nothing on those connections names a session.
• The same bug appears there. Bob's start-up calls (/admin/v1/profile, /inference/v1/model/info) and Bob's tunnel rows were filed inside a Claude Code session.

Proposed fix

Scope is Claude Code and Bob. Their headers (X-Claude-Code-Session-Id, X-Task-Id) are already in the default list. The mechanism doesn't depend on which header is used, so any agent whose header is configured in session.id_headers gets the same treatment. An agent without one lands in default instead of in another agent's session.

1. Find which process opened each connection. On macOS the kernel's TCP table (what netstat -anv reads) gives the client PID of each connection to the proxy, and reading it needs no root. I checked: each Claude Code window shows up with its own PID.
2. Map processes to sessions.
   • A request carrying a session header tells the proxy "PID p is session S".
   • Traffic without a header from p, or from anything p started (Bash-tool gh/git/curl, MCP servers), goes to S.
   • Anything else goes to default instead of the most recent writer.
   • The map is keyed on PID plus process start time, so a reused PID can't inherit a session.
3. Keep start-up traffic. A process talks before its first request with a header, for example a connectivity probe or MCP initialize/tools/list. That traffic goes to a pending bucket for the process. When the process names its session, the bucket moves into it: Rekey covers a new session, and a new store merge operation covers --resume.
4. File every CONNECT row under its connection's session. Opaque tunnels are filed when they open. Bridged tunnels are filed just before their first decrypted request, so abctl's fold keeps working. This also closes H3.

Limits:

• A process that switches sessions (/clear, /resume, or Bob's IDE running concurrent tasks): its traffic without a header follows its most recent session.
• macOS first. Linux keeps today's behaviour until a /proc lookup exists.
• In-cluster sidecars are unchanged. They keep the A2A correlation that ActiveSession() exists for.

Estimated size: about +1,400–2,100 lines across 12–15 files, mostly tests. Step 4 on its own is about +600–800 lines. It fixes the ~84% of CONNECT rows whose connection carries a request with a header, but not the rest.

Assisted-By: Claude (Anthropic AI) noreply@anthropic.com