Description

The websocket handshake path arms a new connect-auth timeout watchdog when the first connect request is parsed. However, the handler does not mark the connection as "connect in progress" before awaiting async auth, and it continues to treat the socket as "not yet connected" as long as getClient() is null.

As a result, a client can send additional connect request frames while the first one is still awaiting resolveConnectAuthState(...) (or other async steps). Each additional connect frame executes:

• clearHandshakeTimer()
• armConnectAuthTimer() (which clears and re-sets the timeout)

This allows an unauthenticated peer to indefinitely postpone the auth-timeout by repeatedly sending connect frames, keeping the socket and the pre-auth connection budget slot held, which can lead to resource exhaustion / connection starvation.

Vulnerable code:

const connectParams = frame.params as ConnectParams;
clearHandshakeTimer();
armConnectAuthTimer();
​// ... await resolveConnectAuthState(...)

Because the handler awaits auth before calling setClient(...), getClient() remains null and subsequent messages re-enter the same handshake path.

Recommendation

Prevent handshake state-machine re-entry while auth is in progress.

Options:

1. One-shot arm: only allow armConnectAuthTimer() to run once per connection, and ignore/close on subsequent connect frames until the first finishes.

2. Explicit state: introduce a handshakeState/flag like connectInProgress (or set handshakeState to "connecting") before the first await, and reject subsequent connect frames when this flag is set.

Example (sketch):

let connectInProgress = false;

if (!client) {
  if (connectInProgress) {
    send({ type: "res", id: parsed.id, ok: false, error: errorShape(ErrorCodes.INVALID_REQUEST, "connect already in progress") });
    close(1008, "duplicate connect");
    return;
  }
  connectInProgress = true;
  clearHandshakeTimer();
  armConnectAuthTimer();
  try {
    const state = await resolveConnectAuthState(...);
    ​// ... continue handshake
  } finally {
    connectInProgress = false;
  }
}

Also consider not clearing/rearming the watchdog if it is already armed, so repeated frames cannot extend the deadline.

Best possible solution:

Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review.

Do we have a high-confidence way to reproduce the issue?

Yes by source inspection: while connect auth awaits, getClient() remains null and another valid connect frame can re-enter the PR's pre-client path and rearm the watchdog. I did not run a live socket repro in this read-only review.

Is this the best way to solve the issue?

No as submitted; the connection/message-handler boundary is plausible, but the deadline must be one-shot or duplicate connect frames must be rejected before this is the best fix. The branch also needs rebase and real behavior proof.

Security review:

Security review needs attention: The diff introduces a concrete Gateway preauth DoS bypass unless duplicate in-flight connect frames cannot reset the auth watchdog.

• [high] Resettable connect-auth watchdog — src/gateway/server/ws-connection/message-handler.ts:426
  Repeated valid pre-client connect frames can rearm the proposed watchdog before a client is registered, allowing an unauthenticated peer to extend the auth window and hold Gateway resources.
  Confidence: 0.9

AGENTS.md: found and applied where relevant.

What I checked:

• stale F-rated PR: PR was opened 2026-04-29T01:35:55Z, is older than 60 days, and the latest review rated it F.
• proof blocker: real behavior proof is missing and proof tier is F, so this branch is not merge-ready without contributor follow-up.
• no human follow-up: live comments and timeline hydrated by apply contain no non-automation activity after the ClawSweeper review.

Likely related people:

• steipete: Git history on the Gateway auth/handshake files shows Peter Steinberger carried major refactors and timeout/auth wiring work that this PR builds on. (role: recent adjacent Gateway auth contributor; confidence: medium; commits: f5408d82d210, bbdfba569440, 0c1f491a0262; files: src/gateway/server/ws-connection/message-handler.ts, src/gateway/server/ws-connection.ts, src/gateway/handshake-timeouts.ts)
• vincentkoc: The source and replacement PR discussions credit Vincent Koc with the ProjectClownfish repair path and targeted Gateway validation around this exact timer/auth behavior. (role: branch repair coordinator and adjacent Gateway contributor; confidence: medium; commits: 9a16c5bb391a, 98422460f08d; files: src/gateway/server/ws-connection/message-handler.ts, src/gateway/server/ws-connection.ts, src/gateway/server/ws-connection/message-handler.post-connect-health.test.ts)
• sashakhar1: The replacement PR is based on sashakhar1's closed source PR and the linked issue comments include the slow-auth Gateway reproduction that motivated this repair. (role: original reproducer and source PR author; confidence: medium; commits: 683db39fdab9, 98422460f08d; files: src/gateway/server/ws-connection/message-handler.ts, src/gateway/client.ts)
• Dallin Romney: Current-main blame on the central WebSocket connection and message-handler lines points to a recent broad commit touching these files, so this is a routing signal rather than semantic ownership. (role: recent current-main toucher; confidence: low; commits: 2ec670898018; files: src/gateway/server/ws-connection/message-handler.ts, src/gateway/server/ws-connection.ts)
• openclaw/openclaw-secops: CODEOWNERS explicitly covers src/gateway auth files, and this PR changes preauth/connect-auth timing around authorization. (role: CODEOWNERS reviewer team; confidence: high; files: .github/CODEOWNERS, src/gateway/server/ws-connection/message-handler.ts)

Codex review notes: model internal, reasoning high; reviewed against 738b2be4b49b.