Problem

The relay server rejects new extension connections with 409 Extension already connected when extensionWs is non-null, even if the underlying socket is already in CLOSING or CLOSED state.

This commonly happens with Manifest V3 service workers — Chrome kills the worker after ~30s of inactivity, and when it restarts and attempts to reconnect, the old socket is still lingering in a half-closed state. The user sees a connection failure and has to manually toggle the extension.

Fix

Two small, targeted changes to extension-relay.ts:

1. Only reject with 409 when the existing socket is actually OPEN. If the socket is stale (CLOSING/CLOSED), terminate it and accept the new connection.

2. Add an identity guard in the close handler so that a late-firing close event from a replaced socket does not wipe state belonging to the newer active connection.

What this does NOT change

• No changes to the Chrome extension itself (background.js)
• No new dependencies or permissions
• Existing behavior when a live extension is connected is unchanged (still returns 409)

Testing

Tested by attaching the extension, restarting the gateway (simulating stale socket), and reconnecting — the extension now connects cleanly without requiring a manual toggle.

Greptile Summary

Fixes a reconnection issue in the Chrome extension relay where stale WebSocket connections (in CLOSING/CLOSED state) prevented new extension connections from being established. The fix checks socket state before rejecting with 409, terminates stale sockets, and adds an identity guard in the close handler to prevent late-firing close events from wiping state of newer connections. This resolves the common Manifest V3 service worker scenario where Chrome kills the worker after ~30s inactivity, leaving lingering half-closed sockets.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The changes are surgical and well-targeted: they add defensive checks for socket state and identity without altering the core connection logic. The fix correctly handles the stale socket race condition by checking readyState before rejection and preventing old close handlers from interfering with new connections via identity comparison. Both changes align with WebSocket best practices.
• No files require special attention

_{Last reviewed commit: 21c2e68}

_{(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!}