Bug: Interactive Token Source main agent always times out exitCode 3 v0.17.1

[ajcohan-droid]

Summary

Interactive Token Source main agent always times out exitCode 3 v0.17.1

Environment

• Maestro version: 0.17.1
• Operating system: macOS (Darwin Kernel Version 25.5.0: Mon Apr 27 20:41:15 PDT 2026; root:xnu-12377.121.6~2/RELEASE_ARM64_T6041, 25.5.0)
• Install source: Packaged build (release build or locally packaged)
• Agent/provider involved: Not provided
• SSH remote execution: Not provided

Steps to Reproduce

1. Set Token Source to Interactive in Maestro settings.
2. Open any session (fresh or existing).
3. Send any query, including a simple one-sentence prompt.
4. Observe: tab naming subprocess returns correct answer in ~4s; main agent times out at ~302s with exitCode: 3.

Expected Behavior

Main agent should return a response to the user's query when Token Source is set to Interactive mode.

Actual Behavior

Main agent spawns with --permission-mode plan and --append-system-prompt, then exits after exactly ~302 seconds with exitCode: 3 and response: 'undefined'. Occurs on large sessions, fresh sessions, and simple one-sentence queries alike. Stderr shows: 'maestro-p: --print requires a value; ignoring' and 'maestro-p: ignoring --verbose — headless-mode flag, not forwarded to the TUI.'

Additional Context

The tab naming subprocess (uses a different maestro-p invocation path, passes --print without a value) works correctly and returns accurate responses. In session 3ef996e3-fe67-4a8d-8d94-aea1c3ea8481, the tab naming subprocess returned 'Texas' (the correct answer to the main prompt) while the main agent timed out. The answer is being generated but is not captured or returned by the main agent path. Model in use: sonnet[1m]. Tested on Apple Silicon macOS.

Screenshots / Recordings

None

[pedramamini]

Thanks for the unusually detailed report, @ajcohan-droid - the session id, the "Texas" tab-name vs. timed-out main agent, and the exact stderr lines made this one quick to pin down.

Root cause: With Token Source set to Interactive, Maestro drives the Claude TUI via maestro-p instead of claude --print. When your agent is in read-only / plan mode, the --permission-mode plan flag gets forwarded to the TUI. In plan mode the model finishes its turn by calling ExitPlanMode, which parks the TUI on a blocking "Ready to code?" approval prompt. maestro-p is headless and has no human to answer that prompt, so the model never emits the end_turn signal the runner waits for. The turn then idles until the --max-wait watchdog fires at ~302s with exitCode: 3, and because that's an error path it discards the answer it had already captured (hence response: undefined). That also explains why the tab-namer, which doesn't run in plan mode, returned the right answer.

(The --print requires a value and ignoring --verbose stderr lines are expected and harmless on the interactive route - they're just maestro-p declining the headless-only flags. Not the cause.)

Proposed fix: #1118. It teaches maestro-p to treat an ExitPlanMode call as a completed turn: it folds the plan body into the result and finalizes successfully (exitCode 0), mirroring how headless claude --print --permission-mode plan returns the plan and exits. Read-only intent is preserved - nothing executes, you just get the plan back instead of a 5-minute timeout.

We think this gets it. Would you mind following #1118 and letting us know if it matches what you're seeing? If you're able to run a local build from that branch, confirmation that interactive plan-mode turns now return promptly would be hugely helpful before we ship it.

[ajcohan-droid]

Happy to help and thanks for your quick attention @pedramamini . Also, I'm using Claude to help me debug this, since I'm a bit out of my depth here. So let me know if this doesn't make sense or you need more info.

I think #1118 might only cover part of it. My latest failing run never entered plan mode but timed out identically.
Session 030eff39-3807-4b7b-b59c-bd19b19dade1, similar query ("Which state do we have an addendum for?"). The main agent spawned without --permission-mode plan, and the queue logged isReadOnlyMode: false — yet I still got durationMs: 302395, exitCode: 3, response: "undefined", message: "timeout". Tab-namer succeeded again (~4s, "Texas").