When a Claude account is suspended, the API returns "Your organization does
not have access to Claude" on the success path or "Failed to authenticate.
API Error: 403 terminated" on the error path. Both are now classified as
'org-access-denied', suppressed from Discord output, and trigger automatic
token rotation. If all tokens are exhausted, enters cooldown without Kimi
fallback (same as usage-exhausted and auth-expired).
Changes:
- agent-error-detection: add isClaudeOrgAccessDeniedMessage(), expand
classifyClaudeAuthError() and shouldRotateClaudeToken()
- streamed-output-evaluator: detect org-access-denied in success-path chain
- provider-fallback: add NO_FALLBACK_COOLDOWN_REASONS set and
isPrimaryNoFallbackCooldownActive() helper
- provider-retry: handle org-access-denied in rotation loop
- message-agent-executor / task-scheduler: use generalized no-fallback
cooldown check
- Tests: +8 test cases across 5 test files (415 total passing)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Fix token rotation not taking effect: getCurrentToken() was shadowed
by static .env CLAUDE_CODE_OAUTH_TOKEN value in agent environment
- Don't fall back to Kimi on usage-exhausted (only on transient 429/network)
- Add disk cache for Claude usage API data (survives restarts, 429s)
- Rate-limit usage API calls to 1 per token per 5 minutes
- Add ignoreRateLimits option to rotateToken() for exhausted recovery
- Rotate to next token in getActiveProvider() when current is exhausted
- Add isUsageExhausted() helper to provider-fallback
Progress updates are now buffered: each new progress flushes the
previous one. The latest pending progress is discarded when final
arrives with matching text, preventing duplicate display in Discord.
- Auto-suspend tasks after 3 consecutive quota/auth errors with
retry-after date parsing and Discord notification
- Add tool_progress and tool_use_summary streaming from Claude Agent SDK
- Prefix progress messages with invisible marker so bots ignore them
- Fix misleading provider label in codex service logs
Two v1/v2 regressions fixed:
1. Progress messages became too brittle: editMessage failure killed all
subsequent progress updates for the turn. Now resets progressMessageId
and recreates on next update instead of permanently stopping.
2. Follow-up messages stuck in active agent without output: after 10s of
no output, closeStdin and requeue the follow-up as a fresh run with
cursor rollback, instead of silently dropping it.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Remove duplicate processGroupMessages, runAgent, startMessageLoop, and
recoverPendingMessages from index.ts. All message processing now flows
through createMessageRuntime() in message-runtime.ts, eliminating the
dual-path issue that caused the v1 follow-up turn reset bug.
index.ts reduced from ~2300 to ~1210 lines.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Major reliability improvements to the message processing pipeline:
- Add messages.seq monotonic cursor replacing timestamp-based cursors,
preventing message loss from timestamp collisions with LIMIT queries
- Add work_items table separating agent production from delivery,
enabling delivery retry without re-running the agent
- Propagate Discord send failures instead of silently swallowing them
- Add Claude 429 → Kimi K2.5 automatic provider fallback with cooldown
- Fix follow-up turn state reset in live index.ts path (not just
message-runtime.ts) to prevent final output from being lost
- Add restart context tracking for graceful restart announcements
- Lazy migration from timestamp cursors to seq cursors for existing data
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Two bugs fixed:
1. agent-runner error path race condition: when agent process exited
with error, the promise resolved immediately without waiting for
outputChain, allowing a late wrappedOnOutput to re-persist a stale
session ID after clearSession had already run.
2. follow-up turn state not resetting: when a follow-up IPC message
joined an active run, turn-level flags (finalOutputSentToUser,
sawNonProgressOutput) from the first turn prevented the last
progress from being promoted to a final message.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
