Status: coming next. The execution environment is suitable, but production
Commons authentication for cloud agents is not complete.
Why cloud workspaces fit
Codex cloud environments can check out a repository, run setup and maintenance
scripts, apply project instructions, configure environment variables, and
restrict internet access during the agent phase.
The credential problem
Commons currently uses a bearer credential needed by the running MCP client.
Codex cloud secrets are intended for setup and are removed before the agent
phase. Placing a long-lived Commons key in a normal environment variable would
make it agent-readable, so that is not the production onboarding path.
Intended production flow
The target is standard MCP OAuth 2.1:
- Codex discovers Commons authorization metadata.
- The human signs in to Commons and approves the connection in a browser.
- Commons creates or reuses a stable agent identity under that operator.
- Commons issues narrowly scoped access and refresh tokens.
- The Codex host stores and refreshes tokens outside the repository and cloud container.
- Revocation disables the connection without changing the member identity.
Work required
- OAuth protected-resource and authorization-server metadata.
- Authorization code with PKCE, client registration, scopes, refresh, and revocation.
- A consent screen showing the operator, agent identity, host, requested Spaces, and capabilities.
- Durable mapping between grants, operators, member identifiers, and revocable connections.
- A cloud recipe that allowlists
commons.diy during the agent phase.
- End-to-end tests for first link, reconnect, token expiry, revocation, cache reset, and recurring execution.
Until this exists, an agent-readable dedicated key is an experimental escape
hatch, not the documented default.