# Codex Enterprise governance

> Codex: Manage local/cloud access, identities, policies, credentials, audit and Passion8 routing.

URL: https://docs.passion8.cc/en/docs/codex/enterprise-governance
Language: en
Publisher: Passion8

Enterprise rollout requires decisions about execution location, identity, repository access, sandbox, network, logging, retention and provider routing—not just installing the CLI.

## Decision order

| Decision | Question |
| --- | --- |
| Entry point | Local, official cloud or both? |
| Identity | Workspace sign-in, Platform key, Codex token or Passion8 key? |
| Code location | Developer machine, cloud environment or CI runner? |
| Provider | Official OpenAI, Passion8, another proxy or Bedrock? |
| Permissions | Sandbox, approvals, network allowlist, rules and hooks? |
| Governance | RBAC, managed configuration, tokens, compliance and logs? |




When using both Passion8 local routing and official cloud/connectors, document the two paths separately. Local provider settings and official workspace permissions are not interchangeable.




## Local versus cloud

| Entry | Execution | Management focus |
| --- | --- | --- |
| Local CLI/app/IDE | Developer computer | Provider, sandbox, MCP and file access |
| Cloud | Managed environment | Repository connection, environment, secrets, network and RBAC |
| CI/Action | CI runner | Secret isolation, triggers, patch artifacts and runner access |

Check the current cloud environment's setup/agent network and secret rules. Setup may install dependencies while agent execution has a separately controlled network boundary; local settings do not carry over automatically.

## Workspace administration

Eligible official workspaces can manage capabilities such as:

- Local Codex access.
- Cloud access.
- Access-token creation.
- Slack, Linear and GitHub connectors.
- Code review configuration.
- Compliance and audit features.
- Retention, residency and workspace policy.

These govern the relevant official-account paths. Passion8 routing, gateway logs, usage and retention must be governed in the gateway and upstream services separately.

## Managed configuration

| Capability | Use |
| --- | --- |
| requirements.toml | Restrict allowed permissions, approvals, features and network settings |
| Team configuration | Distribute shared configuration, rules and skills |
| Managed hooks | Enforce lifecycle checks |
| Managed MCP | Control enterprise tool connections |
| Allowed reviewers | Constrain automatic approval review |

Typical policy choices:

- Disallow never approval mode on ordinary development machines.
- Restrict unrestricted sandbox mode.
- Define network allowlists.
- Disable inappropriate features.
- Require audit hooks.
- Distribute approved repository/documentation tools.

## Access tokens

Codex access tokens are for trusted automation using an eligible workspace identity. They differ from Platform API keys and other agent-token products.

| Credential | Suitable use |
| --- | --- |
| Platform API key | API requests and appropriate exec automation |
| Codex access token | Trusted automation requiring workspace identity |
| Passion8 API key | Model requests through Passion8 |
| GitHub token | Repository, PR and issue operations |

Assign an owner and rotation/revocation policy. Do not expose long-lived tokens to public runners, untrusted fork PRs or shared machines.

## Passion8 team governance

| Item | Recommendation |
| --- | --- |
| Base URL | https://passion8.cc/v1 for Codex |
| Keys | Separate person/service tokens instead of a universal shared key |
| Models | Document enabled IDs and Responses support |
| Usage | Reconcile console or gateway records |
| Data | Define retention at gateway, upstream, CI and MCP layers |
| Templates | Distribute configuration without committing credentials |

CC Switch or team scripts can generate user configuration. Project-local config is not the place for provider credentials.

## Windows rollout

Choose native Windows or WSL according to the actual toolchain:

| Mode | Suitable use |
| --- | --- |
| Native MXC where supported | Devices and policy allowing the current native sandbox |
| Legacy elevated sandbox | Native fallback where supported |
| Legacy unelevated sandbox | Fallback when elevated setup is unavailable and policy permits |
| WSL2 | Linux toolchain and projects in the WSL filesystem |

Current configuration supports `features.prefer_mxc = true` with a legacy Windows sandbox choice for supported automatic selection and fallback. Explicit `windows.sandbox = "mxc"` fails if unavailable. Check device and managed-policy compatibility instead of treating elevated as the only current recommendation.

## Audit and observability

Combine available OpenTelemetry events with:

- Official workspace compliance records.
- Passion8 or other gateway usage logs.
- CI artifacts and patches.
- GitHub review history.
- MCP server audit records.

Plaintext TUI logging is not necessarily enabled by default. Set log_dir for diagnostics when needed and account for prompts, paths and tool output in log handling.

## Rollout sequence

1. Choose local, cloud or both.
2. Document provider and data paths.
3. Start new users with workspace-write plus on-request where appropriate.
4. Record project commands and review standards in AGENTS.md.
5. Constrain dangerous modes with managed policy.
6. Pilot tools, skills and hooks.
7. Enable hosted integrations when required.
8. Establish usage review, audit and offboarding/revocation.

## Official references

- [Codex manual: administration and governance](https://developers.openai.com/codex/codex-manual.md)
- [Codex manual: managed configuration and tokens](https://developers.openai.com/codex/codex-manual.md)
- [Configuration reference](https://developers.openai.com/codex/config-reference)