Repository navigation
fix(acp): failed turns hide the real cause behind "Internal error" / "Failed to open … provider session" #58
Description
Observed (owner's live T3 0.1.2, statev2 snapshot 2026-11-02)
Runs: 317 completed, 40 cancelled, 32 failed, 9 interrupted. 27 of the 32 failures were Hermes ACP instances (24 hermes-clean-acp, 3 hermes-acp-local). The error items the user saw:
| Shown in the thread | Count | Actual cause (server log) |
|---|---|---|
Failed to open acpRegistry provider session provider-session:… |
11 | AcpProcessExitedError: exited with code 1 ← bws-env-exec: credential setup failed (TimeoutExpired); or exited after signal SIGKILL (host memory pressure) |
Internal error |
8 | Hermes gateway closed the socket with 1009, frame over 8 MiB (kvnloo/hermes-agent#688) |
The provider event stream closed unexpectedly… |
4 | ACP process died mid-turn (incl. after a worktree handoff) |
The provider could not start this turn… |
4 | same wedged session as Internal error |
The cause is only in boot-service.log, so the user had to ask an agent to find it each time ("one of my t3 chats keeps failing", "why is it failing?", /retry).
Request
When an ACP process exits or rejects session open, the error item shows a bounded tail of its stderr/exit reason (exit code or signal, last N stderr lines, redacted) and says whether a retry can help. That works on web, desktop and mobile through the existing error item.
Upstream
Same class as upstream issue 5943 (setPermissionMode failure masks provider CLI startup death) and 17072 (ACP session fails to open with no cause). Join those; don't open a new venue.
Acceptance
- Error item includes exit code/signal and a redacted stderr tail for ACP open/turn failures.
- Same text on mobile.
- Focused tests for exit-code, signal and timeout cases.
Activity