platform/docs/chat-panes-next-session.md

Multi-pane chat: where it stands, and the one open bug

Written 2026-08-10 at the end of a long session, so the next one starts from evidence instead of re-deriving it.

The open bug

A pane pointed at a REMOTE server shows Disconnected and never gets a reply. The pane opens, lists and reads that server's conversations fine (HTTP with the API key works). Sending produces nothing.

Console, repeatedly:

WebSocket connection to 'wss://officer.pastilhas.dev/api/chat/ws?token=ofk_…' failed:
WebSocket is closed before the connection is established.

The same message also appears for the LOCAL pane's ws://localhost:9010/..., yet the local pane works and shows connected. So the message alone is not the bug — something closes the remote one and it never comes back.

Ruled out, each by direct test — do not re-test these

• The server. wss://officer.pastilhas.dev/api/chat/ws?token=<the same ofk_ key> opens on the first try from outside the browser. Tested twice: with no Origin header, and with Origin: http://localhost:9010 (what the browser sends). Both OPEN.
• The key. Same key, works over HTTP for /chat/sessions, and opens the socket above.
• Websocket auth not understanding API keys. upgradeWs in server.tsx uses resolveAuthToken, the same resolver as the HTTP doors, and comments say so explicitly. chat is an execution capability and the owner passes isWsProviderAllowed.
• Officer being stale on alpha. Pulled and restarted; the failure persists.
• Send being dropped. Fixed in 243bd04 — useChatWebSocket.send used to return silently when the socket was not OPEN. It now queues and flushes on open. That fix is real and worth keeping, but it did not resolve this: a socket that never opens never flushes.

Where to look next

src/workspaces/hooks/src/useChatWebSocket.ts, and specifically what happens with SEVERAL instances mounted at once — one per pane.

The handlers look individually correct: close returns early when socketRef.current !== socket, the effect depends on [url] alone, and isCleaningUpRef is reset on mount. What has NOT been established is how those interact across three simultaneous instances plus React's dev StrictMode double-invoke, which creates, closes and recreates every socket on mount.

Concrete things to try, cheapest first:

1. Instrument before theorising. Log url, readyState and instance identity on every create, open, close and retry. The console message says a close arrived during CONNECTING; it does not say who called it. That is the whole question and it is one log line away.
2. Check whether the effect re-runs. url is a string, so it should be stable — but chatSocketUrl(serverId, localStorage.getItem('BEARER_TOKEN')) is recomputed every render, and if anything makes serverId flip (say, a pane re-resolving its target) the URL changes and the socket is torn down mid-handshake, forever.
3. Suspect the transcript resolver in ChatPane. It calls onTargetChange on success, which rewrites the tab state, which produces a new target object for every pane in that tab. If that ever loops, every pane's socket is rebuilt on every pass and none survives the handshake.
4. Try one pane pointed at the remote server, alone. If it connects, the bug is about multiplicity rather than about the remote server, which would be the single most useful fact to have.

What works, so it is not re-litigated

• Adding a second server by URL + ofk_ key, verified against /api/auth/me before storing.
• Per-pane server chips; the list, the directory picker and the transcript all follow the pane's server.
• Tabs, splitting to three panes, closing, renaming a tab, and the tab name winning the page title.
• Reading a remote conversation end to end.

Setup facts worth not rediscovering

• Andre's Mac key lives in agent memory. Alpha needs its own; the one in the console above is alpha's.
• bun dev on the Mac serves a STALE bundle whenever a new file is added to a workspace package — the symptom is X is not a function for an export that plainly exists. Restart it; do not debug it.
• The Mac is https://macbook.pastilhas.dev through NPM on alpha (100.64.0.1 → Mac 100.64.0.9:9010), and the cert is valid under strict TLS.