# Applying A Permission Policy

Use before launching a team during agent-guided setup, or when a user asks to configure...

- Repository: https://github.com/mvschwarz/openrig (8541 stars)
- Category: AI and agents
- License: Apache-2.0
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add mvschwarz/openrig --skill applying-a-permission-policy -g -a claude-code -y`
Codex: `npx skills add mvschwarz/openrig --skill applying-a-permission-policy -g -a codex -y`
Cursor: `npx skills add mvschwarz/openrig --skill applying-a-permission-policy -g -a cursor -y`
Gemini CLI: `npx skills add mvschwarz/openrig --skill applying-a-permission-policy -g -a gemini-cli -y`

## Description

Use before launching a team during agent-guided setup, or when a user asks to configure OpenRig command permissions, reduce repeated native approval prompts, or apply a selected rig/seat permission policy.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 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**

The rest: https://github.com/mvschwarz/openrig/blob/HEAD/packages/daemon/assets/plugins/openrig-core/skills/applying-a-permission-policy/SKILL.md