yolo

yolo

disable-model-invocation: true is deliberate. Only the owner can start this mode. In Claude Code, type /yolo --for <duration> [scope]. In Codex, type $yolo --for <duration> [scope]. Only --for is required; scope text and --merge or --no-merge are optional. off needs no duration.

Choose the runtime

Codex: Read references/codex.md and follow that path. It authorizes all necessary work in the scope, including deploys and releases, subject to strict verification. Check the active permissions and prompt once for Full access when needed, as the reference explains. The Codex instructions are complete; do not inherit the Claude standing-grant limits or stops below. Do not run the Claude grant steps below in Codex.

Claude Code: Follow the hook-backed path below. A missing Claude grant never selects the Codex path. For any other runtime, report that it is unsupported and stop.

Claude Code

Without scope text, use only the current task already agreed in this session. State that task before work starts. If no task exists, ask the owner for one. An omitted scope never grants merge permission or includes unrelated work. Merges require --merge or an explicit merge instruction in the scope. The invocation is the approval for that task or scope, never for unrelated work.

The yolo.sh hook does the mechanical part (see docs/hooks.md). When the owner types the command, the hook writes a grant for this session and adds one context line. While the grant lives, the hook approves the permission dialogs of this session, except for a denylist. This skill does the rest: it tells you what the grant lets you decide alone, and where you must still stop.

1. Read the grant line

Find the line the hook added to your context for this command. It starts with one of these:

• YOLO GRANT REMOVED — the owner typed /yolo off. Tell the owner, in one sentence, that every permission default is back. Stop.
• YOLO GRANT ACTIVE — read the session, the expiry, the grant file path, merge: yes|no, and the scope from it. Resolve "the current task in this session" to the agreed task before step 2.
• Neither line — no hook grant is available, so every permission default stays. Tell the owner to check the four yolo.sh entries in docs/hooks.md#yolosh, and stop. Do not start the scope as if it were autonomous.

Do not edit any settings file to make the mode work. The mode must never change settings.json at runtime. Never write or change a grant file or a transcript. Only a /yolo that the owner types starts the mode, and the permission gate checks the transcript for it.

2. The standing grant

Tell the owner, in at most three lines: the scope, merge: yes|no, the expiry, and the stops in step 3. Then start the work. Do not ask "should I start?".

The owner designates this session as autonomous for the scope in the grant line, and only for that scope. This is the standing grant that the "When designated as autonomous" clause of CLAUDE.md expects. Inside the scope, it is the explicit instruction that these rules ask for:

• Push. Push the branches you create for the scope. Never force-push.
• Plan and audit sign-off. Where a rule says to wait for approval of a plan or an audit, write the plan or audit, state your choice, and continue.
• Pull requests. Open the pull requests the scope needs with /deliver: prove each change works, review it once, and fix the findings. Run /pr-conductor or local attestation only when the scope asks for them.
• Merge, only when merge: yes. Merge each pull request in the scope when its required checks are green and its evidence covers the head SHA. Use the repository's merge path (/merge-pr, or gh pr merge --squash --delete-branch). Deleting the merged pull request's own head branch is part of the merge. When merge: no, stop at a green pull request and report it.

Do not ask "push?", "merge?", "approved?", or "should I continue?" about a decision inside the scope. Make the decision, and record it in the final report.

Every other rule still applies: worktrees from origin/main, TDD, the merge evidence (CI on the head, or the explicit path), the PR body sections, the protected-path Spec ID or no-spec rationale, and the coordination with other sessions.

3. Where you still stop

Stop, report what you found and why you stopped, and ask one question, for each of these:

1. A force push, git reset --hard, or any other command guard-destructive-git.sh asks for.
2. A deletion of a branch or a repository, except the head branch of a pull request you merge in the scope.
3. An rm -r outside your worktree.
4. terraform destroy, tofu destroy, or apply -destroy.
5. A production deploy or a release.
6. A check that fails and that you cannot fix inside the scope. Do not disable, skip, or weaken the check, and do not lower a threshold.
7. A change to owner-approved spec text (docs/specs/).
8. Any work outside the scope. If the scope does not clearly cover a step, treat it as outside.
9. A change to a settings file, a hook, ~/.claude/, or the grant file (except the rm -f in step 4). A change there outlives the grant.

The hook keeps the dialog for items 1 to 5, 7, and 9 when Claude Code would show one. It cannot see items 6 and 8, and it cannot add a dialog that your settings or auto mode would skip. So these stops are your duty, not only the hook's. Do not route around a stop: no bypass variable, no split or encoded command, no script file, and no other session.

If a dialog shows for a step you expected to pass, the grant has possibly expired. Report it, and do not ask the owner to approve a run of dialogs.

4. Finish

When the scope is done, or a stop ends the work:

1. Report the result. Give what is done, what remains, and each pull request with its link, its check state, and whether you merged it. Then give the decisions you made alone under the grant.
2. End the grant, as /yolo off does: remove the grant file named in the grant line with rm -f <grant file>.
3. Tell the owner in one line that the mode is off and every default is back.