## Why
Codex permission profiles provide the new unified filesystem and network
policy model. However,
`codex-action` currently appends `--sandbox` to every `codex exec`
invocation, which explicitly opts
the session into the legacy sandbox model and prevents
`default_permissions` from taking effect.
This makes it impossible for action users to select profiles such as a
read-only workspace with a
narrow network allowlist.
## What changed
- Add a `permission-profile` action input that selects a built-in or
configured profile through
`default_permissions`.
- Omit `--sandbox` when a permission profile is selected.
- Keep existing behavior compatible: when neither input is supplied, the
action still invokes Codex
with the legacy `workspace-write` sandbox; explicit `sandbox` callers
continue to use that model.
- Reject combinations that would silently disable profiles, including an
explicit `sandbox`, the
`read-only` safety strategy, or a sandbox override in `codex-args`.
- Document profile configuration, the Codex CLI `0.138.0` minimum, and
the distinction between
command permissions and process-level `safety-strategy` protections.
- Rebuild the checked-in action bundle.
Example action configuration after defining `public-review` in the
selected Codex home:
```yaml
- uses: openai/codex-action@v1
with:
openai-api-key: ${{ secrets.OPENAI_API_KEY }}
permission-profile: public-review
prompt: Review the public change.
```
See the [Codex permission profile
documentation](https://developers.openai.com/codex/permissions) for the
profile schema.
## Testing
- Add end-to-end command-construction tests with a fake `codex`
executable. These cover the legacy
default, profile selection without `--sandbox`, and incompatible input
combinations.
- `pnpm test`
- `pnpm run check`
## Documentation
After this input is released, the Codex GitHub Action page on
`developers.openai.com` should list
`permission-profile` and explain its relationship with the legacy
`sandbox` input.
Michael Bolin
6b771854be