Problem
When an API call returns a 400 Bad Request or 429 Rate Limit error, cc-connect does not trigger the error hook event. Instead, the error message is written into the session history as a normal assistant response. This causes the bot to get stuck in an unrecoverable error loop.
Observed Behavior
We observed a project (NoteForge) where the bot received 6 consecutive API errors over ~2.5 hours, and the user could not get any response:
19:49 - "Requested token count exceeds the model maximum context length" (400)
21:56 - "invalid character looking for beginning of value" (400) - SSE parse error
21:59 - Same error (retry by user)
22:07 - Same error (retry by user)
22:22 - Same error (retry by user)
22:22 - Same error (auto-retry)
Each error was appended to the session history as a normal assistant message. The error messages themselves were ~500 chars each, and each one increased the context size for the next --resume, making the next request even more likely to exceed the input limit:
prompt length: 200,322 → 200,771 → 201,420 → 201,768 → 201,923 (always above 196,608 limit)
This is a positive feedback loop: error messages increase token count → more likely to exceed limit → more errors → more tokens.
Root Cause
-
400/429 API errors are treated as normal responses, not as error events. The [[hooks]] event = "error" is only triggered for specific internal errors (connection failures, etc.), not for API-level errors that come back as HTTP 400/429 with error content.
-
Error messages are appended to history without truncation. A 500-char API error body is stored verbatim, inflating the context for subsequent --resume calls.
-
No retry logic with session reset. When a 400 error indicates an unrecoverable condition (e.g., input too long), retrying with the same session is guaranteed to fail again. There is no mechanism to detect this and reset the session.
Expected Behavior
-
API errors (400/429/500) should trigger the error hook event, allowing user-defined hooks to handle recovery (e.g., session reset, history compression).
-
Error messages in history should be truncated or marked. At minimum, long API error bodies should be capped (e.g., 120 chars) to prevent the positive feedback loop. Ideally, cc-connect should detect that an assistant response is actually an API error and handle it specially (not count it as normal context for --resume).
-
Detect and break error loops. If consecutive API errors exceed a threshold (e.g., 3 in a row), cc-connect should automatically reset the session or invoke a recovery hook.
Workaround
We implemented a watchdog script that periodically scans session files and truncates any assistant messages starting with "API Error:" to 120 chars. This limits the feedback loop but is reactive rather than proactive. The real fix needs to be in cc-connect itself.
Environment
- cc-connect version: 1.4.1
- Agent: claudecode with
--resume
- Platform: Feishu
- Proxy: MaaS proxy with character-based input limit (~196K chars)
Problem
When an API call returns a 400 Bad Request or 429 Rate Limit error, cc-connect does not trigger the
errorhook event. Instead, the error message is written into the session history as a normal assistant response. This causes the bot to get stuck in an unrecoverable error loop.Observed Behavior
We observed a project (NoteForge) where the bot received 6 consecutive API errors over ~2.5 hours, and the user could not get any response:
Each error was appended to the session history as a normal assistant message. The error messages themselves were ~500 chars each, and each one increased the context size for the next
--resume, making the next request even more likely to exceed the input limit:This is a positive feedback loop: error messages increase token count → more likely to exceed limit → more errors → more tokens.
Root Cause
400/429 API errors are treated as normal responses, not as error events. The
[[hooks]] event = "error"is only triggered for specific internal errors (connection failures, etc.), not for API-level errors that come back as HTTP 400/429 with error content.Error messages are appended to history without truncation. A 500-char API error body is stored verbatim, inflating the context for subsequent
--resumecalls.No retry logic with session reset. When a 400 error indicates an unrecoverable condition (e.g., input too long), retrying with the same session is guaranteed to fail again. There is no mechanism to detect this and reset the session.
Expected Behavior
API errors (400/429/500) should trigger the
errorhook event, allowing user-defined hooks to handle recovery (e.g., session reset, history compression).Error messages in history should be truncated or marked. At minimum, long API error bodies should be capped (e.g., 120 chars) to prevent the positive feedback loop. Ideally, cc-connect should detect that an assistant response is actually an API error and handle it specially (not count it as normal context for
--resume).Detect and break error loops. If consecutive API errors exceed a threshold (e.g., 3 in a row), cc-connect should automatically reset the session or invoke a recovery hook.
Workaround
We implemented a watchdog script that periodically scans session files and truncates any
assistantmessages starting with"API Error:"to 120 chars. This limits the feedback loop but is reactive rather than proactive. The real fix needs to be in cc-connect itself.Environment
--resume