Ralphmode

Ralphmode is a cross-platform permission profile for long-running

ralph

or

jeo

workflows.

It reduces approval friction, but it is not "allow everything everywhere."

The core rule is simple: widen automation only inside a bounded project or disposable sandbox, and keep secrets plus destructive commands explicitly blocked.

When to use this skill

You want

ralph

to iterate without repeated approval popups.

You are setting up the same repo for Claude Code, Codex CLI, and Gemini CLI.

You need a shared safety model: repo-only writes, no secrets reads, no destructive shell by default.

You want a stronger separation between day-to-day automation and true YOLO mode.

Instructions

Step 1: Define the automation boundary first

Before changing any permission mode:

Pick one project root and keep automation scoped there.

List files and commands that must stay blocked:

.env*

,

secrets/**

, production credentials,

rm -rf

,

sudo

, unchecked

curl | sh

.

Decide whether this is a normal repo or a disposable sandbox.

If the answer is "disposable sandbox," you may use the platform's highest-autonomy mode.

If not, use the repo-scoped preset instead.

Step 2: Choose one preset per platform

Use only the section that matches the current tool:

Claude Code: everyday preset first,

bypassPermissions

only for isolated sandboxes.

Codex CLI: use the current official approval and sandbox model first; treat older

permissions.allow

and

permissions.deny

snippets as compatibility-only.

Gemini CLI: trust only the project root; there is no true global YOLO mode.

Detailed templates live in

references/permission-profiles.md

.

Step 3: Apply the profile locally, not globally, unless the workspace is disposable

Prefer project-local configuration over user-global defaults.

Claude Code: start with project

.claude/settings.json

.

Codex CLI: start with project config and repo instructions or rules files.

Gemini CLI: trust the current folder, not

~/

or broad parent directories.

If you must use a user-global default, pair it with a stricter denylist and a sandbox boundary.

Step 4: Run Ralph with an explicit verification loop

After permissions are configured:

Confirm the task and acceptance criteria.

Run

ralph

or the

jeo

plan-execute-verify loop.

Verify outputs before claiming completion.

If the automation profile was temporary, revert it after the run.

Recommended execution contract:

boundary check -> permission profile -> ralph run -> verify -> cleanup or revert

Step 5: Keep "skip" and "safe" separate

Treat these as different modes:

Repo automation: minimal prompts inside a bounded workspace.

Sandbox YOLO: promptless execution in a disposable environment only.

Do not collapse them into one shared team default.

Step 6: Configure Mid-Execution Approval Checkpoints

Static permission profiles (Steps 2–3) reduce friction before a run starts, but they do not stop dangerous operations that arise during execution. Add dynamic checkpoints so that Tier 1 actions are blocked or flagged at the moment they are attempted.

Dangerous operation tiers

Tier

Action

Platform response

Tier 1

(always block)

rm -rf

,

git reset --hard

,

git push --force

,

DROP TABLE

,

sudo

,

.env*

/

secrets/**

access, production environment changes

Block immediately, require explicit user approval

Tier 2

(warn)

npm publish

,

docker push

,

git push

(non-force), DB migrations

Output warning, continue only with confirmation

Tier 3

(allow)

File reads/edits, tests, local builds, lint

Allow automatically

Platform checkpoint mechanisms

Platform

Hook

Blocking

Recommended pattern

Claude Code

PreToolUse

(Bash)

Yes — exit 2

Shell script pattern-matches command; blocks Tier 1

Gemini CLI

BeforeTool

Yes — non-zero exit

Shell script blocks tool; stderr fed to next turn

Codex CLI

notify

(post-turn)

No

approval_policy="unless-allow-listed"

+ prompt contract

OpenCode

None

No

Prompt contract in

opencode.json

instructions

Principle

Combine static profiles (Steps 2–3) with dynamic checkpoints (this step). Platforms with pre-tool hooks (Claude Code, Gemini): use the hook script. Platforms without (Codex, OpenCode): rely on approval_policy and explicit prompt contracts that instruct the agent to output CHECKPOINT_NEEDED: and wait before proceeding with Tier 1 actions. See references/permission-profiles.md for full hook script templates per platform. Examples Example 1: Claude Code sandbox run Use the Claude sandbox preset from references/permission-profiles.md , then run Ralph only inside that isolated repo: /ralph "fix all failing tests" --max-iterations = 10 Example 2: Codex CLI repo-scoped Ralph run Apply the Codex repo preset from references/permission-profiles.md , then run the task. The current official model uses config file settings, not CLI flag overrides: approval_policy = "never" sandbox_mode = "workspace-write" Place this in ~/.codex/config.toml (or a project-local override) and restart Codex before running Ralph. Example 3: Gemini CLI trust-only setup Trust the current project folder, keep explicit file selection, then run the Ralph workflow for that repo only. Best practices Default to the least-permissive preset that still lets Ralph finish end-to-end. Keep secret denylists and destructive command denylists even when approvals are reduced. Use full bypass only in disposable environments with a clear project boundary. Record which preset was applied so teammates can reproduce or revert it. Re-check platform docs when upgrading CLI versions because permission models change faster than skill content. References What are Agent Skills? Agent Skills Specification Permission Profiles Claude Code permissions Codex configuration and rules ChatGPT Codex sandbox and approval modes Gemini CLI trusted folders