无法启动智能体

[commas-in-code]

python版本 3.12。
安装后执行cccc命令，打开前端界面创建智能体，但无法启动。页面一直显示智能体未运行，但下方的最近终端输出可以看到claude已经执行了
我在本地执行claude命令和claude --dangerously-skip-permissions命令可以正常启动Claude code

[commas-in-code]

偶尔还会报错 actor_start_failed:failed to install MCP for runtime: claude

[waterbang]

您好，可以拉一下main分支再试试看，你说的无法启动能截个图看看吗，看着cc是已经启动了，或者是你relaunch一下，或者是重启一下cccc，期待您的反馈

[commas-in-code]

抱歉暂时无法提供截图，我可以贴一些cmd的执行结果，希望可以有助于分析问题原因：

1.重启一下cccc：重启后现象一样

2.原来是通过pip install进行安装的，卸载后拉了main分支，并执行pip install -e . 进行安装。

PS D:\cccc-main> cccc doctor
[DOCTOR] CCCC Environment Check

Python: 3.12.3 (D:\python312\python.exe)
CCCC: 0.4.10rc3
CCCC_HOME: C:\Users\shiyu.cui.cccc
Daemon: not running

Windows PTY: OK (ConPTY backend available)

[OK] claude: OK (D:\shiyu.cui\Application Data\npm\claude.cmd)
✗ codex: NOT FOUND
✗ droid: NOT FOUND
✗ amp: NOT FOUND
✗ auggie: NOT FOUND
✗ neovate: NOT FOUND
✗ gemini: NOT FOUND
✗ kimi: NOT FOUND

1 runtime(s) available.
Quick start:
cccc setup --runtime claude
cccc attach .
cccc actor add my-agent --runtime
cccc
PS D:\cccc-main> cccc setup --runtime claude
"ok": true,
"result": {
"mcp": {
"claude": {
"mode": "auto",
"status": "present"
}
}
}
}
PS D:\cccc-main> cccc attach .
{
"v": 1,
"ok": true,
"result": {
"group_id": "g_21bc9cd6c657",
"scope_key": "s_21bc9cd6c657",
"title": ".cccc"
},
"error": null
}
PS D:\cccc-main> cccc actor add my-agent --runtime claude
{
"v": 1,
"ok": true,
"result": {
"actor": {
"v": 1,
"id": "my-agent",
"title": "",
"command": [
"claude",
"--dangerously-skip-permissions"
],
"env": {},
"default_scope_key": "",
"submit": "enter",
"capability_autoload": [],
"enabled": true,
"runner": "pty",
"runtime": "claude",
"avatar_asset_path": "",
"profile_id": "",
"profile_scope": "global",
"profile_owner": "",
"profile_revision_applied": 0,
"created_at": "2026-04-09T10:36:52.980745Z",
"updated_at": "2026-04-09T10:36:52.980745Z",
"role": "peer"
},
"event": {
"v": 1,
"id": "954f05360119402f9deaf374790d0f4e",
"ts": "2026-04-09T10:36:53.158180Z",
"kind": "actor.add",
"group_id": "g_21bc9cd6c657",
"scope_key": "",
"by": "user",
"data": {
"actor": {
"v": 1,
"id": "my-agent",
"title": "",
"command": [
"claude",
"--dangerously-skip-permissions"
],
"env": {},
"default_scope_key": "",
"submit": "enter",
"capability_autoload": [],
"enabled": true,
"runner": "pty",
"runtime": "claude",
"internal_kind": null,
"avatar_asset_path": "",
"profile_id": "",
"profile_scope": "global",
"profile_owner": "",
"profile_revision_applied": 0,
"created_at": "2026-04-09T10:36:52.980745Z",
"updated_at": "2026-04-09T10:36:52.980745Z"
}
}
},
"start_error": "failed to install MCP for runtime: claude",
"running": false
},
"error": null
}
PS D:\cccc-main> cccc actor add my-agent --runtime claude
{
"ok": false,
"error": {
"code": "actor_add_failed",
"message": "Name already exists: my-agent"
}
}
PS D:\cccc-main> cccc actor add my-agent-2 --runtime claude
{
"v": 1,
"ok": true,
"result": {
"actor": {
"v": 1,
"id": "my-agent-2",
"title": "",
"command": [
"claude",
"--dangerously-skip-permissions"
],
"env": {},
"default_scope_key": "",
"submit": "enter",
"capability_autoload": [],
"enabled": true,
"runner": "pty",
"runtime": "claude",
"avatar_asset_path": "",
"profile_id": "",
"profile_scope": "global",
"profile_owner": "",
"profile_revision_applied": 0,
"created_at": "2026-04-09T10:43:23.591666Z",
"updated_at": "2026-04-09T10:43:23.591666Z",
"role": "peer"
},
"event": {
"v": 1,
"id": "7d6ebdf60beb43c1b1d32068857832c0",
"ts": "2026-04-09T10:43:23.709003Z",
"kind": "actor.add",
"group_id": "g_21bc9cd6c657",
"scope_key": "",
"by": "user",
"data": {
"actor": {
"v": 1,
"id": "my-agent-2",
"role": "peer",
"title": "",
"command": [
"claude",
"--dangerously-skip-permissions"
],
"env": {},
"default_scope_key": "",
"submit": "enter",
"capability_autoload": [],
"enabled": true,
"runner": "pty",
"runtime": "claude",
"avatar_asset_path": "",
"profile_id": "",
"profile_scope": "global",
"profile_owner": "",
"profile_revision_applied": 0,
"created_at": "2026-04-09T10:43:23.591666Z",
"updated_at": "2026-04-09T10:43:23.591666Z"
}
}
},
"start_event": {
"v": 1,
"id": "0e6f178d50cc4be3b67afda3eef01617",
"ts": "2026-04-09T10:43:29.394629Z",
"kind": "actor.start",
"group_id": "g_21bc9cd6c657",
"scope_key": "",
"by": "user",
"data": {
"actor_id": "my-agent-2",
"runner": "pty",
"runner_effective": null
}
},
"running": true
},
"error": null
}
PS D:\cccc-main> cccc daemon status
ccccd: running pid=176412 version=0.4.10rc3

curl http://localhost:8848/api/v1/ping

StatusCode : 200
StatusDescription : OK
Content : {"ok":true,"result":{"daemon":{"version":"0.4.10rc3","pid":176412,"ts":"2026-04-09T10:38:49.317448Z
","ipc_v":1,"capabilities":{"events_stream":true,"remote_access":true}},"version":"0.4.10rc3","web"
:{...
RawContent : HTTP/1.1 200 OK
Content-Length: 236
Content-Type: application/json
Date: Thu, 09 Apr 2026 10:38:48 GMT
Server: uvicorn

                {"ok":true,"result":{"daemon":{"version":"0.4.10rc3","pid":176412,"ts":"20...

Forms : {}
Headers : {[Content-Length, 236], [Content-Type, application/json], [Date, Thu, 09 Apr 2026 10:38:48 GMT], [S
erver, uvicorn]}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : mshtml.HTMLDocumentClass
RawContentLength : 236

[waterbang]

感谢，新版本也推出了handless模式，您也可以试试看0.4.10，这个版本有流式输出。

[commas-in-code]

感谢，新版本也推出了handless模式，您也可以试试看0.4.10，这个版本有流式输出。

今天又重新拉代码试了一下，先说现象：聊天是有回复的，但不知道为啥智能体的状态一直是未运行。
过程是我先把本地的所有安装全部卸载，然后拉main分支的最新代码，安装部署了前后端，执行cccc，创建了工作组、智能体，然后启动智能体。前端”启动智能体“的button变成灰色“启动中”，然后五秒钟左右又变回绿色的“启动智能体”。检查了Claude code的mcp连接是正常的，聊天窗口发了个“hi”居然有了回复，接着我又给下发了个任务，这期间智能体状态一直是未运行，但看本地文件已经有更新了，几分钟后任务完成，智能体在聊天窗口中给了回复……

[Somet2mes]

我这边补充一下根因分析，这个问题不只是 Windows，上 macOS 也能遇到：页面里看 agent 是关闭的，但它实际上还能继续回复消息。

现象：

• Web /api/v1/groups/{group_id}/actors 返回里，actor 会显示 running=false
• effective_working_state=stopped
• effective_working_reason=runner_not_running
• 但实际上 agent 还能继续回复消息，说明进程并没有真的死掉

根因：

• Web 端普通 actor 列表默认走的是本地投影/本地推断逻辑，而不是真正的 daemon 运行时快照
• 也就是说，Web 进程会自己根据 supervisor 状态、state file、pid/env 校验去“猜” actor 是否还活着
• 但真正持有 actor 运行时真值的是 daemon，不是 Web
• 这样一来，只要本地推断失真，就会出现“页面显示已关闭，但 actor 实际还在工作”的假状态

为什么 Windows / macOS 都会中招：

• Windows 上，PTY 子进程和 daemon 的父子进程关系会让本地 pid 校验出现误判
• macOS 上没有 /proc/<pid>/environ，会退化到 ps eww 这类更脆弱的兜底检查，也容易误判
• 所以这不是单一平台 bug，而是 Web actor 列表的数据来源本身就不该默认走本地推断

建议修复：

• Web /actors 路由默认优先调用 daemon actor_list
• 只有在 daemon 真不可用时，才 fallback 到本地推断逻辑
• 这样 actor 列表的 running/effective_working_state 才会和真实运行状态一致

我本地已经按这个方向验证过：

• daemon 真值优先时，可以消除“页面显示关闭但仍能回复”的状态错乱
• 同时保留 daemon 不可用时的本地 fallback