Skip to content

fix: auto-trust handles all prompt scenarios cleanly - #98

Merged
aterrylu merged 1 commit into
mainfrom
terry/auto-trust-v2
Mar 31, 2026
Merged

fix: auto-trust handles all prompt scenarios cleanly#98
aterrylu merged 1 commit into
mainfrom
terry/auto-trust-v2

Conversation

@aterrylu

Copy link
Copy Markdown
Owner

Summary

Improves the auto-trust watcher to only watch for prompts that will actually appear, disposing immediately instead of waiting for the 30s timeout.

Problem

The watcher always expected both prompts (trust + channels), so when only one appeared, it waited the full 30s timeout before cleaning up. Noisy logs and unnecessary PTY watching.

Fix

attachStartupWatcher(pty, expectChannels) now receives a boolean based on whether --dangerously-load-development-channels is in the spawn args. The watcher only watches for prompts that are expected:

Scenario Expected Behavior
Untrusted dir + dev channels trust, channels Answers both, disposes
Untrusted dir, no dev channels trust only Answers trust, disposes immediately
Trusted dir + dev channels trust, channels Channels answered, 15s timeout
Trusted dir, no dev channels trust only 15s timeout (nothing to answer)

Timeout reduced from 30s → 15s.

🤖 Generated with Claude Code

The watcher now receives expectChannels based on spawn args instead of
always watching for both prompts:

- Trust prompt: always expected (CC may ask for any directory)
- Channels prompt: only when --dangerously-load-development-channels used

This means the watcher disposes immediately after answering the expected
prompts instead of waiting for the 30s timeout. Timeout also reduced
from 30s to 15s since prompts appear within the first few seconds.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@aterrylu
aterrylu force-pushed the terry/auto-trust-v2 branch from c385178 to 6803873 Compare March 31, 2026 04:29

@nox-0x nox-0x left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clean fix — building the expected-prompt list from spawn args avoids unnecessary PTY watching and the 30s timeout hang when only one prompt fires. Logic is sound: trust is always included, channels conditional, closure captures correct array length. 15s timeout is a reasonable reduction. Good work.

@aterrylu
aterrylu merged commit d9ddd7a into main Mar 31, 2026
1 check passed
@aterrylu
aterrylu deleted the terry/auto-trust-v2 branch March 31, 2026 04:30
aterrylu added a commit that referenced this pull request Apr 3, 2026
Rewrites the startup watcher to be simpler and more reliable:

- Multiple needle variants per prompt (with/without spaces) for
  robustness across terminal widths
- 5-Enter burst at 50/200/500/1000/2000ms on detection — covers
  timing variations where the TUI isn't ready
- Mark answered immediately on detection (no race condition from
  buffer clearing)
- Don't clear buffer — both prompts can be detected in same chunk
- Timeout logs unanswered prompts for diagnostics
- PTY write failure stops further retries

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
aterrylu added a commit that referenced this pull request Apr 3, 2026
fix: auto-trust handles all prompt scenarios cleanly (#98)

Rewrites the startup watcher to be simpler and more reliable:

- Multiple needle variants per prompt (with/without spaces) for
  robustness across terminal widths
- 5-Enter burst at 50/200/500/1000/2000ms on detection — covers
  timing variations where the TUI isn't ready
- Mark answered immediately on detection (no race condition from
  buffer clearing)
- Don't clear buffer — both prompts can be detected in same chunk
- Timeout logs unanswered prompts for diagnostics
- PTY write failure stops further retries

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants