Applying A Permission Policy

Applying a permission policy

Configure the user's chosen permissions in the harness that runs the agent. OpenRig operating posture, native command rules, sandbox access and launch flags are separate controls. A command rule grants execution capability, not authority to invent tasks, publish work or change another host.

Ask once before team launch

Reuse an existing explicit choice for these harnesses and this scope from the user's onboarding context; do not ask again. Existing rules are configuration, not evidence of consent to expand their scope. Preserve them without expansion.

For a team with no explicit policy, recommend keeping the team default. Claude already allows ordinary rig commands, project reads and common tests, while lifecycle commands ask. Codex already has writable workspace and pod state; its on-request policy does not guarantee lifecycle prompts. Explicit policies, seat choices and named Codex profiles keep their existing meaning.

Native restrictions can still prompt for installs, commits, other shell commands and writes outside writable roots. With the Claude team default, an allow does not override lifecycle ask rules: rig up, rig down and the other listed lifecycle commands still ask even after Yes. Do not promise prompt-free operation.

Only offer additional persistent allowances when wanted, for the selected project or explicitly user-wide scope, or to adjust an explicit seat policy:

Remember these selected OpenRig commands in your native settings for this project? This is separate from the team launch default; stricter rules and Claude lifecycle asks remain. Yes / No — keep the team default

• Yes: require an affirmative answer, then apply the procedure below only at the agreed scope. Do not replace ask/deny rules or substitute user-wide settings when project rules are unsupported.
• No / no answer: leave settings and any existing explicit choice unchanged. With no policy selected, keep it unset; never record none to mean keeping the team default. Do not repeat the question during this setup.

A recommendation is not consent. Broader filesystem/network access requires its own explicit choice; permission consent is separate from launch approval.

Remember an explicit Yes or No in the existing onboarding/project context the agent already reads: choice, harnesses and scope. For Yes, record the exact files and entries added, any pre-existing equivalents, and the loading/verification result. Do not add a preference service or native configuration key. No answer is not a remembered No. Offer broader permissive operation only as a separate explicit opt-in; the setup question does not select a builtin policy or mode.

Choose the intended scope

Outside the setup question above, use an existing explicit choice; otherwise explain these options and ask which the user wants. Do not reopen the menu after an answered setup question or ask again for routine steps already authorized.

If repeated approvals later interrupt the work, name the actual commands and offer a scoped adjustment then. Keep the existing choice until the person accepts a change; do not promise to adjust later and silently leave the burden with them. Do not reopen an answered choice for each routine operation.

A whole-family allow matches all rig verbs, including lifecycle, topology/config changes and commands that can launch other processes. It is not a read-only grant, but stricter ask/deny rules still win. Offer narrower prefixes such as rig ps or rig queue list when that better fits the request. Do not widen a choice to arbitrary shell execution, an entire interpreter or a generic shell wrapper.

Apply the choice for the user

1. Identify the target seat, executable/version, launch settings and config roots: HOME, CODEX_HOME or CLAUDE_CONFIG_DIR as applicable. They may differ between operator, daemon and seat. Resolve the intended user's/project's files before writing; do not repair another home to make the paths agree.
2. Read relevant existing permission rules and managed restrictions. Select the intended scope: one project or the user's sessions. Consult installed native help and official references below when formats differ.
3. Prepare a concrete diff. Preserve deny/ask rules, approval/sandbox posture, hooks, auth, MCP, model settings and unrelated values. An allow must not erase a stricter rule or managed requirement. Report a real conflict instead of silently bypassing it. Check both bare and actual absolute command spellings: a restriction on one may not match the other. If a new allowance would evade a stricter restriction, leave that addition unapplied and report the conflict; do not switch spellings to bypass it.
4. Back up touched files and merge only authorized additions, avoiding duplicates. Recognize equivalent existing entries (including Claude's legacy Bash(rig:*)); leave their markers untouched. Reapplying the same choice must be a no-op when the required entries already exist, including no timestamp-only rewrite. The agent performs these edits; hand-editing is an option, not a required user chore. Apply the selected scope without another conversational permission round. Native enforcement still applies.
5. Read back the diff and validate the format. Confirm how that version loads changes. If it requires a new session, preserve work and use its supported resume path within the user's authority; a file write does not prove that an existing conversation loaded it.
6. Verify an ordinary matching operation twice in the target conversation and check that an unrelated command gained no matching rule. Use harmless reads, not destructive probes. Report effective settings, their source and remaining prompts; a command already allowed by the launch default does not prove a new persistent rule loaded. A parser match alone does not establish native behavior.

Give the user this short undo: “Undo the OpenRig command allowances added by this setup; keep my other rules.” The agent removes only the recorded entries from their exact files, preserving pre-existing rules and subsequent edits. For Codex remove those prefix_rule entries; for Claude remove those permissions.allow entries. Delete a newly created rules file only if it still contains solely this setup's additions. Never restore the entire backup over later changes. Record the changed choice in the same context and verify native reloading/revocation; other pre-existing allowances may still permit rig. Builtin policy specs remain read-only; customize in user space.