Remote Control：回放事件被重复持久化，且工具权限请求因 can_use_tool 模式错误而失败

[HKLHaoBin]

概述

在使用 ccb rc 配合 Docker Remote Control WebUI 时，已关闭的会话积累了大量重复的历史记录，并且所有工具调用在权限控制路径中都失败了。

这似乎是两个相关的问题：

1. 回放事件被重新摄取并再次作为新事件持久化。
2. 使用 can_use_tool 的工具权限请求未以当前 CLI 接受的响应形状进行处理。

环境

• CLI：ccb --version 报告为 2.8.0 (Claude Code)
• Remote Control 服务器镜像：ghcr.io/claude-code-best/remote-control-server:latest
• 镜像 ID：sha256:a8341e87c1b2fb1065c421dff99c806c30f72602c837099cbc79d0b9bc2ae370
• /health：{"status":"ok","version":"3.3"}
• CLI 端服务器操作系统：Windows Server 2012 R2，通过 OpenSSH 访问
• ccb rc 打印的浏览器 URL 格式：/code/session_<id>?bridge=env_<id>

发生了什么

WebUI 发送了一个简单的提示：

检查一下当前系统是否已安装 Docker。

该会话后来变为 inactive，WebUI 显示了大量重复的用户/助手内容。Dashboard 不再显示活跃的环境或会话，但已关闭的会话历史记录仍然可读。

会话元数据示例：

{
  "id": "session_6e64f8a6eea347b083a5c72cad35d288",
  "environment_id": "env_2f33c768da2941df8d9c2a8dc08beb4c",
  "status": "inactive",
  "source": "remote-control"
}

证据：回放重复

会话历史端点返回了约 22 MB 的 JSON：

events=2281
jsonLength=22767230

事件类型统计：

assistant        1481
user              733
control_response   52
control_request     7
permission_response 6
session_status      1
system              1

重复的 payload UUID 包括：

144  3f2f98b6-3e28-4f73-a51a-1b05d98659a1
73   89a507e7-c899-4a82-ad49-000000000001
72   014bee9f-741d-4d0c-8950-ddf1948f5968
72   de00aac7-23b8-43c2-b373-000000000002
72   de00aac7-23b8-43c2-b373-000000000001
72   de00aac7-23b8-43c2-b373-000000000000

容器日志反复显示回放事件通过入口重新进入：

[WS] Replaying 2140 missed event(s)
[WS] Replaying 2163 missed event(s)
[WS] Replaying 2228 missed event(s)

[WS] <- bridge (inbound): sessionId=session_... type=user ... "isReplay":true
[WS] <- bridge (inbound): sessionId=session_... type=assistant ...
bus publish: sessionId=session_... type=assistant dir=inbound seq=...

这表明回放事件在持久化和再次发布之前没有被忽略或去重。

证据：工具权限失败

工具调用失败不是因为 Docker 未安装。它们在执行之前的权限/控制路径中就失败了。

历史记录中包含如下工具权限错误：

Tool permission request failed: [
  {
    "code": "invalid_union",
    "errors": [
      [
        {
          "expected": "record",
          "code": "invalid_type",
          "path": ["updatedInput"],
          "message": "Invalid input: expected record, received undefined"
        }
      ],
      [
        {
          "code": "invalid_value",
          "values": ["deny"],
          "path": ["behavior"],
          "message": "Invalid input: expected \"deny\""
        },
        {
          "expected": "string",
          "code": "invalid_type",
          "path": ["message"],
          "message": "Invalid input: expected string, received undefined"
        }
      ]
    ],
    "path": [],
    "message": "Invalid input"
  }
]

容器日志中也包含：

control_response ... {
  "subtype":"error",
  "request_id":"...",
  "error":"Unsupported control request subtype: can_use_tool"
}

并行调用随后级联成：

<tool_use_error>Cancelled: parallel tool call Bash(docker --version 2>&1) errored</tool_use_error>

预期行为

• 标记为 isReplay: true 的回放/历史事件不应再次作为新事件持久化。
• 重新连接 WebSocket/会话回放不应成倍增加历史记录大小或重复可见上下文。
• 带有 subtype: can_use_tool 的 control_request 应该被支持，或者被转换为当前 CLI 接受的响应形状。
• 如果工具权限请求失败，WebUI 应将该工具调用显示为失败/错误，而不是显示看起来已成功的 Bash / Glob 工具卡片。

实际行为

• 相同的用户和助手事件被重复持久化了数十次或数百次。
• WebUI 显示了大量重复的上下文块。
• 工具调用反复失败，出现 schema/unsupported-subtype 错误。
• 某些工具卡片在 UI 中显示为已完成，尽管实际的 tool_result 包含权限错误。

备注

前端路由似乎也忽略了 ccb rc 打印的 bridge=env_... 查询参数；会话绑定似乎由 sid/uuid 驱动。这可能是独立的问题，但它使初始会话访问变得混乱。

[HKLHaoBin]

Additional reproduction from a fresh session

I reproduced the issue again with a new session:

/code/session_af5c08e7e59145d589de8fabe9ee889d?bridge=env_8ca03e9dd7d24b7b82b840bb7fd0f313

Steps used

1. Opened the new session page. Initial state was idle and the message input was usable.
2. Sent a low-risk read-only prompt:

请运行一个只读测试命令：echo RCS_REPRO_TEST。不要修改任何文件。

3. The command returned successfully, but the WebUI still showed the Bash tool card as running. The assistant success text was also duplicated in the visible UI.
4. Sent another read-only prompt:

请运行只读命令：docker --version 2>&1。不要修改任何文件。

5. The WebUI showed a Bash permission request. I clicked Approve.
6. The tool call failed with the same permission schema issue. The assistant then attempted another Bash call and generated a second permission request.

Fresh session history stats

After this short reproduction, the history already had duplicated UUIDs:

events=53
jsonLength=77763

assistant          26
user               18
control_response    3
control_request     2
system              2
permission_response 1
result              1

Top duplicated UUIDs:

8  cfd892ed-ec76-42da-84be-68f6a89877f7
4  816f6681-ac6b-45ab-8548-be04078efc53
4  bd18296d-a588-4158-90d3-000000000000
4  bd18296d-a588-4158-90d3-000000000001
4  d8e2ee9a-bcbd-4214-81ac-000000000000
4  d8e2ee9a-bcbd-4214-81ac-000000000001
4  dd76c574-5c88-4233-ae52-3ac660d8772d

Fresh session errors

The permission request looked like this:

{
  "request": {
    "subtype": "can_use_tool",
    "tool_name": "Bash",
    "input": {
      "command": "docker --version 2>&1",
      "description": "Run read-only docker version check"
    }
  }
}

The resulting tool failure was again:

Tool permission request failed
invalid_union
updatedInput: Invalid input: expected record, received undefined
behavior: Invalid input: expected "deny"
message: Invalid input: expected string, received undefined

The server also later emitted:

Unsupported control request subtype: can_use_tool

The server log showed the replay loop starting in this fresh session too:

[WS] Client inactive for 60s on session=session_af5c08e7e59145d589de8fabe9ee889d, closing dead connection
[WS] Replaying 29 missed event(s)
[WS] <- bridge (inbound): ... "isReplay":true
bus publish: ... dir=inbound seq=30

So this is reproducible from a clean session and does not depend on the previously polluted session.