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: <reason> 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 sandbox Ralph run

For sandbox ralph runs, use the CLI flags directly:

codex -c model_reasoning_effort="high" --dangerously-bypass-approvals-and-sandbox -c model_reasoning_summary="detailed" -c model_supports_reasoning_summaries=true

For repo-scoped (non-sandbox) runs, use the config file approach from references/permission-profiles.md:

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 sandbox or trust-only setup

For sandbox ralph runs, use --yolo mode:

gemini --yolo

For normal repo automation, trust the current project folder with explicit file selection and run the Ralph workflow for that repo only. See references/permission-profiles.md for details.

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.

ralphmode