feat: add yolo mode to auto-approve permission prompts#240
Merged
anandgupta42 merged 5 commits intomainfrom Mar 18, 2026
Merged
feat: add yolo mode to auto-approve permission prompts#240anandgupta42 merged 5 commits intomainfrom
anandgupta42 merged 5 commits intomainfrom
Conversation
Claude Code ReviewThis repository is configured for manual code reviews. Comment |
- Add `ALTIMATE_CLI_YOLO` / `OPENCODE_YOLO` env var flag - Add `--yolo` as global CLI option (works with any subcommand) - Add `--yolo` on `run` command for convenience - Auto-approve (`"once"`) instead of auto-reject in headless mode - Auto-approve in TUI via env var (skip permission prompt rendering) - Global `--yolo` propagates to env var in middleware so all paths pick it up - Explicit `deny` rules still enforced (safety by construction) - Update permissions docs with Yolo Mode section Closes #239 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
anandgupta42
force-pushed
the
feat/yolo-mode
branch
from
d1d301e to
a3a50b9
Compare
![sentry[bot]](https://avatars.githubusercontent.com/in/12637?s=60&v=4){kind=small}
Comment on lines
+39
to
+41
| // altimate_change start - yolo mode: auto-approve all permission prompts | ||
| export const ALTIMATE_CLI_YOLO = altTruthy("ALTIMATE_CLI_YOLO", "OPENCODE_YOLO") | ||
| // altimate_change end |
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
- CRITICAL FIX: `Flag.ALTIMATE_CLI_YOLO` was a static `const` evaluated at module load time. `--yolo` CLI flag sets env var in middleware (after load), so the flag was always `false` via CLI. Now uses `Object.defineProperty` dynamic getter like other runtime-set flags. - Add yolo mode handling to ACP agent (`acp/agent.ts`) — was missing, causing ACP clients to hang on permission prompts even with `--yolo` - Replace unsafe `(opts as any).yolo` with `"yolo" in opts && opts.yolo` - Add 26 adversarial tests covering: - Dynamic getter timing (the critical bug) - Env var parsing edge cases (empty, arbitrary strings, case) - Deny rules cannot be bypassed by yolo (safety by construction) - Case sensitivity of deny patterns - Multiple ruleset merge precedence - Error type distinction (`DeniedError` vs `RejectedError`) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- CRITICAL FIX: `Flag.ALTIMATE_CLI_YOLO` was a static `const` evaluated at module load time. `--yolo` CLI flag sets env var in middleware (after load), so the flag was always `false` via CLI. Now uses `Object.defineProperty` dynamic getter like other runtime-set flags. - Add yolo mode handling to ACP agent (`acp/agent.ts`) — was missing, causing ACP clients to hang on permission prompts even with `--yolo` - Replace unsafe `(opts as any).yolo` with `"yolo" in opts && opts.yolo` - Add 26 adversarial tests covering: - Dynamic getter timing (the critical bug) - Env var parsing edge cases (empty, arbitrary strings, case) - Deny rules cannot be bypassed by yolo (safety by construction) - Case sensitivity of deny patterns - Multiple ruleset merge precedence - Error type distinction (`DeniedError` vs `RejectedError`) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
1. **E2E tests** (6 new integration tests): - Deny rules throw `DeniedError` even with yolo env var set - Allow rules pass without asking (no yolo needed) - Ask rules wait for reply, resolved by yolo-style `"once"` - Multiple simultaneous permissions all resolved individually - Mixed deny + ask: deny throws, ask waits for reply - Config-driven permissions: yolo auto-approves `ask`, can't touch `deny` 2. **TUI yolo indicator** — `△ YOLO` warning in footer status bar when yolo mode is active, matching existing permission warning style 3. **Minor review fixes:** - Remove duplicate `--yolo` option from `run.ts` (inherited from global) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
- Remove "subcommand flag" section (duplicate --yolo removed from run.ts) - Explain WHY deny rules are still enforced (thrown before events) - Document env var precedence (ALTIMATE_CLI_YOLO overrides OPENCODE_YOLO) - Mention TUI footer indicator Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Adds
--yoloflag to theruncommand andALTIMATE_CLI_YOLO/OPENCODE_YOLOenv var to auto-approve all permission prompts without interactive confirmation.runmode: auto-approves ("once") instead of auto-rejectingdenyrules are still enforced — safety guaranteed by architecture (deny throws before events are published)Type of change
Issue for this PR
Closes #239
How did you verify your code works?
bun run build— compiles successfullybun run typecheck— passesbun test— all pre-existing tests pass (13 pre-existing failures unrelated to this change)altimate-code run --yolo "list files"auto-approves permissionsChecklist