-
-
Notifications
You must be signed in to change notification settings - Fork 80.7k
[Bug]: Add client identity labels to gateway WebSocket connections #79601
Copy link
Copy link
Open
Labels
P2Normal backlog priority with limited blast radius.Normal backlog priority with limited blast radius.bugSomething isn't workingSomething isn't workingbug:behaviorIncorrect behavior without a crashIncorrect behavior without a crashclawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.ClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:needs-security-reviewClawSweeper marked this issue as needing security-sensitive review.ClawSweeper marked this issue as needing security-sensitive review.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.impact:otherThis issue has meaningful maintainer-visible impact outside the owned taxonomy.This issue has meaningful maintainer-visible impact outside the owned taxonomy.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.maturity:stableIssue affects a taxonomy feature currently scored M4/M5.Issue affects a taxonomy feature currently scored M4/M5.staleMarked as stale due to inactivityMarked as stale due to inactivity
Description
Metadata
Metadata
Assignees
Labels
P2Normal backlog priority with limited blast radius.Normal backlog priority with limited blast radius.bugSomething isn't workingSomething isn't workingbug:behaviorIncorrect behavior without a crashIncorrect behavior without a crashclawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.ClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:needs-security-reviewClawSweeper marked this issue as needing security-sensitive review.ClawSweeper marked this issue as needing security-sensitive review.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.ClawSweeper found a high-confidence source-level issue reproduction.impact:otherThis issue has meaningful maintainer-visible impact outside the owned taxonomy.This issue has meaningful maintainer-visible impact outside the owned taxonomy.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.Very strong issue quality with high-confidence source-level or clear reproduction.maturity:stableIssue affects a taxonomy feature currently scored M4/M5.Issue affects a taxonomy feature currently scored M4/M5.staleMarked as stale due to inactivityMarked as stale due to inactivity
Type
Fields
Priority
None yet
Bug type
Behavior bug (incorrect output/state without crash)
Beta release blocker
Yes
Summary
WebSocket connections in gateway/ws logs are identified only by opaque UUIDs (e.g. conn=9366836e). When a connection times out or closes unexpectedly, there is no way to determine which subsystem or client initiated it. This makes diagnosing startup races and handshake failures extremely difficult.
Steps to reproduce
Expected behavior
Clients should send a client-id field during the WS handshake. The gateway should log this on connect and include it on all subsequent log lines for that connection:
conn=9366836e client=browser-sidecar peer=127.0.0.1:50491
Actual behavior
WebSocket connections in gateway/ws logs are identified only by opaque UUIDs (e.g. conn=9366836e). When a connection times out or closes unexpectedly, there is no way to determine which subsystem or client initiated it. This makes diagnosing startup races and handshake failures extremely difficult.
OpenClaw version
2026.4.15
Operating system
Windows 11 (10.0.26200, x64)
Install method
npm global
Model
openai/gpt-5.4 (primary) with fallbacks anthropic/claude-sonnet-4-6, anthropic/claude-opus-4-7
Provider / routing chain
openclaw → openai (direct API key, no proxy/gateway router)
Additional provider/model setup details
Default route is openclaw → openai (direct API key auth).
Fallback chain: openai/gpt-5.4 → anthropic/claude-sonnet-4-6 → anthropic/claude-opus-4-7.
No cloudflare-ai-gateway or openrouter in this setup.
Auth profiles configured under auth.profiles.openai:default (mode: api_key).
Config lives in ~/.openclaw/openclaw.json under agents.defaults.model and plugins.entries.
Logs, screenshots, and evidence
Impact and severity
No response
Additional information
No response