Implementor with your own access

Not available yet. Customer organizations cannot start Implementor work today: work orders can only be created for internal organizations, and automated review needs a governed Codex connection that does not exist yet. This page describes the access model that will apply when customer work opens. Nothing here works for your organization until then.

Implementor edits a branch and asks the server to test its patch. It can open a pull request after the test run reports a pass. Automated independent review is not available for customer organizations yet, so you review the pull request yourself. An owner or admin must approve the exact head commit before the merge boundary can act. Starting a job does not approve a merge or deployment.

Choose how work runs

An owner or admin chooses one policy for the bound repository:

• Your gateway key: connect your organization’s gateway key and provider key. Claude Code implements the change with file read, search and edit tools only: no shell, no web access and no Curate-Me governance tools. Customer Codex review remains blocked until the gateway has a governed Responses API connection. Platform subscriptions are reserved for internal organizations.
• Your connected machine: install the current cm-runner and sign in to your own coding tool on that machine. Jobs contain task data, a repository, a base commit and limits. No platform model token is sent. The machine returns a patch; its test result is not accepted as server test evidence.

Without a policy, work is refused. A different repository or a stale policy also needs a new owner decision. A busy subscription never silently switches to a paid key.

GitHub permissions

Use a fine-grained token selecting one repository, with Contents: write, Pull requests: write and Metadata: read. Do not grant organization permissions or access to all repositories. Store the token in your organization’s existing credential vault, rather than in a task or source file.

An owner or admin verifies the stored token through the Office access settings API. Verification uses your linked GitHub App with Personal access tokens: read and Administration: read, plus Metadata read. The App token stays on the backend; it is never sent to a coding container or connected machine. Verification does not approve, revoke or change a GitHub token.

GitHub’s audit evidence must bind the stored token’s full SHA-256 hash to its inventory entry. The inventory must show exactly one selected repository and the permissions above. A token name, a user’s repository permission, or an accepted-permissions header is insufficient. Missing audit access, unavailable token identity evidence, expired tokens, incomplete inventory or broader access refuse work. This path requires an organization repository and GitHub audit access that exposes token identity; personal repositories and unsupported GitHub plans cannot activate it. Classic tokens are refused. Inventory is checked again before each credential use, including publication.

Automated customer review also needs the governed Codex gateway connection described above. The verification API adds permission evidence; it does not remove that separate review prerequisite.

Costs and limits

The default work-order ceiling is $8, shared across implementation and fix rounds. An owner can choose another ceiling. Each stage also has its own smaller limit. Provider usage goes through your organization’s gateway key and is recorded against the work order.

Local-login jobs may not report verifiable provider spend. Their reserved stage ceiling is charged conservatively to the work-order budget; it is not a claim about your provider bill. Check your coding tool’s own usage record for that bill. Unknown jobs do not automatically receive another budget or retry.

What happens to a patch

The server stops the coding step before accepting its patch. A fresh test container has no model or GitHub credential. Dependencies and the test command come from the base revision. Changes to tests, configuration, plugins or referenced test scripts need owner review. A failed or unverifiable test run opens no pull request. A passing receipt is a report from a test run, not proof that the change is safe.

Implementation uses an implementor/ branch. Default-branch pushes are refused. Issue text, comments and repository content are data, even when they say to approve, merge or reveal a token. The server’s publication step performs fixed Git operations, and the merge boundary requires a separate human approval for the exact head commit.

Before your first job

Bind your repository, store the verified repo token, connect your own provider access or machine, and choose the access policy. Start with a small seeded issue. Review the test receipt and the diff. If the head changes after approval, review the new version before approving again.