ralphmode（ralphmode 命令行）

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.
• You need one portable mental model for vendor-specific permission features: settings, rules, and hooks.

Portable mental model

Treat each platform as three layers:

• Settings — choose the default repo-safe preset versus sandbox-only YOLO preset.
• Rules — define the boundary: repo-only writes, secret/path denylist, and Tier 1 checkpoint conditions.
• Hooks — enforce dangerous-edge behavior when the platform supports pre-tool interception; otherwise fall back to approval policy plus prompt contracts.

If you keep those layers separate, the profile stays portable even when vendor syntax changes.

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 settings 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: Write the rules layer separately from the preset

Do not hide all safety logic inside the settings file alone. Record the shared rules in repo instructions, team docs, or the hook script itself:

• repo-only mutation scope
• secret/path denylist (.env*, secrets/**, credential files)
• Tier 1 commands that always require a checkpoint (rm -rf, force-push, destructive DB commands, sudo)
• when to stop and output CHECKPOINT_NEEDED: <reason>

This matters most on platforms where hooks are weak or absent, because the rules layer becomes the durable fallback.

Step 5: Run Ralph with an explicit verification loop

After settings and rules are configured:

1. Confirm the task and acceptance criteria.
2. Run ralph or the jeo plan-execute-verify loop.
3. Verify outputs before claiming completion.
4. If the automation profile was temporary, revert it after the run.

Recommended execution contract:

boundary check -> settings preset -> rules contract -> ralph run -> verify -> cleanup or revert

Step 6: 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 7: 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

Platform checkpoint mechanisms

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.

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