App-host (AppView) RPC export table goes stale during long sessions; page can no longer call backend APIs

[yorkane]

Environment

• OpenCodex gateway: 2.1.0 (f6fd79c) + PR fix(compatibility): support delegated worktree shell environment pattern #52 (b5c61e2), Linux, headless Electron runner
  (.data/runtime/official-electron-runner/linux-x64/opencodex-gateway, flags: --no-sandbox --disable-setuid-sandbox --disable-dev-shm-usage --headless --disable-gpu)
• Official runtime: ChatGPT Desktop for Linux 26.908.40834 (build 318576267-1789148373000); also reproduced on 26.903.61454, 26.908.31748, 26.820.71523
• Access: browser (web-shell) over LAN, single user, gateway bound to 127.0.0.1

Symptom

After a session has been running for a while (idle periods produce nothing), the gateway log starts
spewing and never recovers until the gateway is restarted:

Failed to register AppView RPC services errorMessage="no such export ID: 622"
    at oee.ensureResolvingExport (.../.data/cache/codex-official-bundle/.vite/build/src-DJnwJvdz.js:709:36337)
Failed to register AppView RPC services errorMessage="no such entry on exports table: -1"
    at e.evaluateImpl (...)
Failed to register AppView RPC services errorMessage="MessagePort message error."
[electron-message-handler] sa_server_request_failed attachAuth=true attachIntegrityState=true
    error={"name":"Error","message":"no such export ID: 1", ...}
[electron-message-handler] Failed to broadcast thread state patches conversationId=01a04794-... error=no such export ID: 1

User-visible effect: the page can no longer perform backend API requests (usage / account / remote
control etc.), and thread state / activity stops syncing for the affected conversations.
Reloading the page does NOT recover it (measured: +4 sa_server_request_failed after Page.reload);
only systemctl restart ryensx-opencodex.service clears it.

Counts (single box, ~6 days, one user)

signal	total
Failed to register AppView RPC services	5359
sa_server_request_failed (no such export ID: 1)	37924
Failed to broadcast thread state patches	91480 (concentrated on 9 conversations, max 532 in one)

Idle 3-minute window: 2 new log lines, 0 failures → this is not a retry loop, it is accumulated state.

Direct evidence of the trigger

Every burst begins immediately after the gateway drops an app-host response to a dead client:

[2026-09-14T04:14:52.396Z] [ws-hub] send_to_missing_client {"channel":"codex_desktop:message-for-view","type":"mcp-response","requestId":"08fa6265-..."}
[2026-09-14T04:14:52.396Z] [ws-hub] send_to_missing_client {"channel":"codex_desktop:message-for-view","type":"mcp-response","requestId":"84bef983-..."}
[2026-09-14T04:14:52.399Z] [ws-hub] send_to_missing_client {"channel":"codex_desktop:message-for-view","type":"mcp-response","requestId":"bef99bc5-..."}
Failed to register AppView RPC services errorMessage="no such entry on exports table: -1"
Failed to register AppView RPC services errorMessage="no such export ID: 622"
...
(node:3185805) MaxListenersExceededWarning: Possible EventEmitter memory leak detected.
                 65 destroyed listeners added to [WebContents]. MaxListeners is 64.

Note the MaxListenersExceededWarning on [WebContents] (65 destroyed listeners): one AppView appears
to be registered per browser connection on the shared hidden webContents and they are never released
(the hidden window is never destroyed), while no such export ID: 1 shows the page-side RPC peer is
calling into an export table that no longer exists.

What we tried to reproduce (all clean, so it is accumulation, not a single code path)

probe (Chrome for Testing via CDP)	result
fresh page load, 25 s idle	0
load → cut network 20 s (WS drops) → restore (page auto-reconnects, no reload)	0
page A open, then page B opens (second tab), then B closes, then reload A	0 AppView, small sa_server_request_failed drift
normal human usage over hours/days	reproduces, then permanent until gateway restart

Suspects

1. rememberRequestRoute(channel, invokeArgs, clientId) keeps routing to a clientId that no longer has a
   live socket → send_to_missing_client drops mcp-response frames → the page-side app-host RPC never
   completes its export registration. Related history: issue Chat history disappears after browser WebSocket reconnect #27 / PR fix(gateway): restore app-host relay after websocket reconnect #28 (restore app-host relay after websocket reconnect).
2. Official main registers an AppView per codex_desktop:connect-app-host on the shared hidden webContents
   and only cleans up on webContents destroyed, so registrations accumulate (65 > 64 listeners).
   Would the gateway need to dispose the previous AppView explicitly when a page reconnects / a relay is replaced?

Current mitigation

A 3-minute watchdog restarts the gateway when the per-interval delta of these log lines exceeds a
threshold (AppView ≥ 30 or sa_server_request_failed ≥ 90). It works, but it is a sledgehammer:
every recovery costs a ~60-90 s gateway restart and a page refresh.

Questions

• Is there an intended way for the gateway to tear down / rebind an AppView for a still-alive hidden
  webContents (e.g. when closeAppHostRelays(ws, "replaced") runs)?
• Should mcp-response frames be dropped (and the route purged) once a clientId has no live socket,
  or should the request be failed back to the caller instead?

[yorkane]

Follow-up: deterministic reproduction + the leaking listener, with a trace

We managed to reproduce it on a freshly restarted gateway by just cycling page connections, and captured
the listener source with NODE_OPTIONS=--trace-warnings on the gateway process.

1. The accumulating listener

(node:3253520) MaxListenersExceededWarning: Possible EventEmitter memory leak detected.
                65 destroyed listeners added to [WebContents]. MaxListeners is 64.
    at _addListener (node:events:590:17)
    at WebContents.addListener (node:events:608:10)
    at WebContents.once (node:events:652:8)
    at new jA (/opt/ryensx-opencodex/.data/cache/codex-official-bundle/.vite/build/main-DaMR-wdT.js:583:13404)
    at O0e.createAppHost (/opt/ryensx-opencodex/.data/cache/codex-official-bundle/.vite/build/main-DaMR-wdT.js:1365:23742)
    at /opt/ryensx-opencodex/.data/cache/codex-official-bundle/.vite/build/main-DaMR-wdT.js:1391:19208
    at connectOfficialAppHostPort (/opt/ryensx-opencodex/gateway/runtime/ipc/official-runtime.cjs:2197:11)

Un-minified, the two official-side frames are:

// main-DaMR-wdT.js:1365:23742  — inside O0e.createAppHost(...)
browserTabs: new jA(c.iabTabMentions, e),      // e === the hidden renderer WebContents

// main-DaMR-wdT.js:583:13404  — class jA
constructor(e, t, n = FA()) {
  super();
  this.iabTabMentions = e;
  this.origin = t;
  this.connectChromeProviders = n;
  t.once(`destroyed`, () => this[Symbol.dispose]());   // <-- one more listener per createAppHost()
}

So every createAppHost() — i.e. every browser app-host connect driven by connectOfficialAppHostPort() —
allocates a fresh host object graph on the same, long-lived hidden WebContents and registers one more
destroyed listener that can only be released when that WebContents is destroyed. In web mode that window is
never destroyed, so hosts and listeners accumulate permanently, and the AppView/RPC sessions attached to them
are exactly the peers that later answer no such export ID / no such entry on exports table.

(Static check: main-*.js contains 54 *once("destroyed") registrations; the gateway itself adds none on
WebContents — grep -rn "webContents.on(|once(" over gateway/runtime is empty.)

2. Recipe (no human interaction needed)

1. systemctl restart ryensx-opencodex.service (fresh process, counters at zero)
2. Connect a page, hold ~7 s, disconnect; repeat 24 times (headless Chrome hitting http://127.0.0.1:3737/)

Observed inside that window (2628 log lines):

signal	count
MaxListenersExceededWarning … 65 destroyed listeners	1 (crossed 64 around connect ~18–24, so ≈2–3 listeners per page)
Failed to register AppView RPC services	39 (no such export ID: 346…, no such entry on exports table: -1 / 351 / -47)
[ws-hub] send_to_missing_client (mcp-response to a dead clientId)	28
sa_server_request_failed (no such export ID: 1)	83

After that the state stays broken: reloading the page does not recover it, only restarting the gateway does.

3. Possible directions (purely suggestions)

1. Reuse one app host per hidden WebContents instead of allocating one per connect, or
2. Dispose the host when the relay is closed — the object already exposes Symbol.dispose, so an explicit
   dispose on relay close would drop the destroyed listener as well, or
3. Model it as a modification point in the compatibility kernel: bind the app-host lifetime to the
   codex_desktop:connect-app-host relay lifetime instead of to WebContents.destroyed.

Happy to test a candidate patch against this recipe (the 24-connect loop reproduces it in ~3 minutes).

[yorkane]

Proposed a gateway-side fix in #54 (with the 24/40-connect reproduction recipe and before/after numbers).

On our box the patch is live: after 40 connect/disconnect cycles the destroyed listener count stays flat at 23
(before: crossed the 64 limit inside ~20 connects), and Failed to register AppView RPC services /
sa_server_request_failed both went to 0 in the same window. Page behaviour and app-host traffic are unchanged
while connected.

It is a lifetime workaround on the gateway side; we agree the cleaner fix is probably on the official-runtime side
(reuse one app host per hidden WebContents, or a dispose hook when its port closes). Happy to rework it.