ulpi-io 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
ralphto 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, uncheckedcurl | 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,
bypassPermissionsonly for isolated sandboxes. - Codex CLI: use the current official approval and sandbox model first; treat older
permissions.allowandpermissions.denysnippets 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
ralphor thejeoplan-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_policyand explicit prompt contracts that instruct the agent to outputCHECKPOINT_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.