You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Reframed from the auto-filed body into a concrete triage decision.
Why ClawDEA cares (contract-hardening watch)
ClawDEA writes a temporary MCP config file each session pointing the CLI at its own loopback McpServer (HTTP on 127.0.0.1). That generated JSON must keep validating against Claude Code's evolving mcpServers schema, so this surface is a standing contract-hardening watch rather than a feature request.
Drift in this snapshot (v2.1.159)
New type: "ws" (WebSocket) transport, accepting the same url, headers, headersHelper, timeout, and alwaysLoad fields as http. claude mcp add --transport does not accept ws.
ClawDEA assessment / how to adapt
ws transport — no adoption needed. ClawDEA's server is an in-process loopback HTTP endpoint; WebSocket transport buys nothing here. No code change.
alwaysLoad — already adopted (PR fix: recover JCEF compositor on sleep/wake and display changes (#36) #89). The earlier snapshots only refined its semantics: setting alwaysLoad: true blocks startup until the server connects, capped at the standard 5s connect timeout. Action: confirm a slow local McpServer bind can't stall chat startup past that cap.
Concrete to-do: add (or verify) a guard test asserting ClawDEA's generated MCP config still parses against the documented http shape (type / url / headers / alwaysLoad). Then a future change to the http shape breaks CI instead of needing manual triage — which is the whole point of keeping this surface at triage: issue.
Surface: Claude Code MCP config schema — https://docs.claude.com/en/docs/claude-code/mcp
Latest detected against: Claude Code v2.1.159
Supersedes (closed): #97, #42, #34 — older per-version snapshots of this same surface.
Why ClawDEA cares (contract-hardening watch)
ClawDEA writes a temporary MCP config file each session pointing the CLI at its own loopback
McpServer(HTTP on127.0.0.1). That generated JSON must keep validating against Claude Code's evolvingmcpServersschema, so this surface is a standing contract-hardening watch rather than a feature request.Drift in this snapshot (v2.1.159)
type: "ws"(WebSocket) transport, accepting the sameurl,headers,headersHelper,timeout, andalwaysLoadfields ashttp.claude mcp add --transportdoes not acceptws.ClawDEA assessment / how to adapt
wstransport — no adoption needed. ClawDEA's server is an in-process loopback HTTP endpoint; WebSocket transport buys nothing here. No code change.alwaysLoad— already adopted (PR fix: recover JCEF compositor on sleep/wake and display changes (#36) #89). The earlier snapshots only refined its semantics: settingalwaysLoad: trueblocks startup until the server connects, capped at the standard 5s connect timeout. Action: confirm a slow localMcpServerbind can't stall chat startup past that cap.httpshape (type/url/headers/alwaysLoad). Then a future change to thehttpshape breaks CI instead of needing manual triage — which is the whole point of keeping this surface attriage: issue.References
CliProcess.kt(temp MCP config writer),McpServerFiled automatically by the drift watcher (
.github/workflows/claude-code-drift.yml); triaged manually.