Enterprise governance
Manage local/cloud access, identities, policies, credentials, audit and Passion8 routing.
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
- Choose local, cloud or both.
- Document provider and data paths.
- Start new users with workspace-write plus on-request where appropriate.
- Record project commands and review standards in AGENTS.md.
- Constrain dangerous modes with managed policy.
- Pilot tools, skills and hooks.
- Enable hosted integrations when required.
- Establish usage review, audit and offboarding/revocation.
#Official references
Support
Need help?
For setup, billing, or model issues, email us. Check the status page for uptime.
WeChat / QQ support is available at the bottom right.
