[Bug]

[orbro-orbro]

cc-connect Version

v1.3.0

Operating System

Windows (WSL)

Agent Type

Claude Code

Platform

WeChat Work (企业微信)

Installation Method

npm (npm install -g cc-connect)

Bug Description

cc-connect 在 claudecode 模式下连接个人版的微信（不知道是不是因为这个），处理完第一条用户消息后，后续消息不再得到回复。具体表现为：cc-connect 能够正常接收微信消息（get_updates.buf 持续更新），但 Claude Code SDK侧不再处理这些消息，会话文件停止写入，用户收不到任何回复。只有重启 cc-connect进程才能恢复（有概率恢复正常），但下一轮对话又会再次停滞。

Steps to Reproduce

在微信端chat过程中，就无法连接了

Expected Behavior

。

Actual Behavior

。

Configuration (config.toml)

Logs / Error Output

Additional Context

No response

[github-actions]

👋 Hi @orbro-orbro! Thanks for opening your first issue here!

We'll review it as soon as possible. While waiting, please make sure:

• You've provided enough details about the issue
• Any error messages are included in full
• For feature requests, describe your use case

Thanks for your feedback!

[orbro-orbro]

claude认为：Go 二进制没有正确处理 Claude Code SDK 非交互模式的 session 生命周期。SDK完成一轮后就结束了，cc-connect 却不知道，还在等一个已经不存在的 session 响应新消息。

[chenhg5]

Thanks for the investigation. We have identified two potential race conditions that could cause this issue.

The root cause appears to be a race condition between:

1. Agent process exit
2. Session state cleanup (cleanupInteractiveState)
3. New message processing

What we need from you to further diagnose:

1. Your cc-connect log file showing the agent exit error
2. Are you using Claude Code with --resume or --continue mode?
3. Does the issue happen immediately after the first message, or after some time?

Please provide the requested information so we can pinpoint the exact cause and develop a fix.

[orbro-orbro]

No, cc-connect invokes Claude Code through the SDK in non-interactive mode (entrypoint: sdk-cli, is_interactive:
false). It doesn't use the CLI command line at all, so --resume and --continue flags don't apply — those are CLI-mode
parameters. cc-connect talks to Claude Code via the SDK API, not by shelling out to claude commands.

[orbro-orbro]

after some times

[orbro-orbro]

No, cc-connect doesn't use --resume or --continue. It invokes Claude Code through the SDK in non-interactive mode
(entrypoint: sdk-cli, is_interactive: false).

Here's the full log output from the terminal (captured with cc-connect 2>&1 | tee):

2026/05/13 18:41:49 INFO acquired instance lock path=C:\Users\lenovo.cc-connect.config.toml.lock
2026/05/13 18:41:49 INFO config loaded path=C:\Users\lenovo.cc-connect\config.toml
time=2026-05-13T18:41:49.666+08:00 level=WARN msg="allow_from is not set — all users are permitted."
time=2026-05-13T18:41:49.670+08:00 level=INFO msg="session: loaded from disk" sessions=1
time=2026-05-13T18:41:49.672+08:00 level=INFO msg="platform ready"
time=2026-05-13T18:41:49.672+08:00 level=INFO msg="engine started" agent=claudecode
time=2026-05-13T18:41:49.675+08:00 level=INFO msg="api server started"
time=2026-05-13T18:41:49.675+08:00 level=INFO msg="cc-connect is running"

No explicit "agent exit error" is printed. The bug manifests silently: cc-connect receives WeChat messages
(get_updates.buf keeps updating) but never forwards them to the SDK. The session file stops being modified after the
first response. The attached telemetry files from the Claude Code side show: tengu_sdk_result returns success with
num_turns: 1 and stop_reason: end_turn, then tengu_sdk_stall is logged, and subsequent messages are never processed.
It looks like after the SDK completes one turn, cc-connect's session reference becomes stale and new messages aren't
dispatched to a new SDK query.

[orbro-orbro]

cc-connect-agent-exit.log

1p_failed_events.af9c5b09-33e6-4163-be41-522d53f2c140.bbbb83e3-2b7b-4f03-b87d-3db6c42175f4.json
1p_failed_events.af9c5b09-33e6-4163-be41-522d53f2c140.c326a4cd-3834-416a-a49c-9858594d9f23.json
1p_failed_events.af9c5b09-33e6-4163-be41-522d53f2c140.21cc788d-44f3-47e6-8427-910fb68db7cd.json
1p_failed_events.af9c5b09-33e6-4163-be41-522d53f2c140.a74a5882-9d05-4cc4-9f57-bdba332af17b.json

[orbro-orbro]

I've attached the relevant log files: the tee-captured cc-connect output, and two Claude Code telemetry files showing tengu_sdk_stall and tengu_tool_use_error events right before the session stops responding.