Fix a failure with Codex or your own API key

Ask Codex to write a fix for a failed run or unresolved code-review findings, and get it as a draft pull request. Time varies with the repository and checks. Built-in viewers can't ask for fixes; members, admins and custom roles granted fix access can.

Codex changes a copy of your code at the commit the run tested, on Zof's platform. Codex never pushes to your repository: the Zof Fix App does that when it opens the draft pull request. A fix never changes a result or a decision.

Fix is on by default. An admin can turn it off, or back on, in Admin › AI model › Advanced. While it is on, Fix sends failure evidence and a copy of the repository at the tested commit to Codex (Azure OpenAI) by default. You can instead choose Claude Code, DeepSeek or Kimi with your own API key. This switch controls every provider. Turning it on or off is recorded in the audit log.

Ask for a fix

1. Open the run in Runs, the pull request in Releases, or a completed review in Code review. For a run of several tests, select the test that failed.
2. Click Fix at the top right of the test or page. On a pull request, Fix is the main button when it's Blocked or Couldn't check. Otherwise it's in the More actions menu there, with the reason when there is nothing to fix.
3. For a test run with a saved branch, Zof uses that branch automatically and checks that it still points to the tested commit. If it has moved, run a new test first. A manual review or older run without a saved branch still asks for a Target branch for the next fix and Check branch.
4. Zof starts straight away once its branch and provider are ready: clicking Fix sends the failure evidence and a copy of your code to your default provider. If you entered a target branch, or your provider isn't ready, click Ask Codex for a fix instead. There is nothing more to click: Zof writes the patch, then opens a draft pull request.
5. The panel says "Codex is reading the failures and writing a fix…". You can close it: the fix keeps going. Click Fix again to see it. Zof only opens the pull request by itself while the panel you started it from is open, so if you closed it, click Open pull request.

On a pull request, Fix is for what is holding it: the failing gates and Zof's reasons at its head. If the pull request has changed since a fix was written, the panel says so; click Write another fix for the new head.

When Fix is dimmed, point at it to see why, such as "Fix once this test or review has finished." or "Nothing failed here, so there is nothing to fix.". "Not available yet: Verification doesn't serve fixes yet." means fixes aren't on yet.

Fix needs a failing test. On a run, Fix sits on the test that found issues. A test that couldn't be checked offers Run this test again, Run again on a run of one test, or Open help for a setup problem on Zof's side. When a test's only failures aren't code, such as the address returning 404 on every check, Fix is dimmed and starts nothing: "This run couldn't test your code: …" names what stopped it. Fix the setup and run it again. On a pull request whose failing checks all couldn't run (say, the unit tests couldn't build), Fix says "This pull request's checks couldn't test the code." with the reason. On a pull request with no release policy published, Fix says "Publish a release policy first: without one, Zof doesn't run checks on pull requests, so there's nothing to fix yet."

Code-review fixes use the current unresolved findings from the completed review. Resolved, dismissed and informational findings are excluded. Backtests cannot generate fixes. If the selected findings change while the fix is being prepared, start again from the current review. The comparison base of a manual review does not choose its publication branch.

Use your own API key

Codex is your initial default. Changing your default requires permission to manage your own settings; permission to run fixes still lets you use your current default. Choose Use for fixes on a connected provider card to save your default for future fixes. The Default badge shows your confirmed choice. Saving a second key does not change it. Manage your personal keys in Admin › AI model › Advanced. These keys belong to your account in this company; they are separate from the company model for runs. In the drawer, Your default fix provider also lists the providers you can run with your own API key: Claude Code · your API key (Anthropic), DeepSeek · your API key and Kimi · your API key (Moonshot). All three are on for every company by default. An admin can turn one off, or back on, under Fixes for this company. A provider your admin turned off isn't listed in the drawer. Changes are audit-logged. Turning one off stops its running fixes at their next request.

Add your key in the drawer or in Admin › AI model › Advanced. On the page, click Add API key on the provider's card to open its key field and setup guidance, then Save API key. You can also open AI model from your account menu. Saving validates the key with a small request to that vendor and does not start a fix. The drawer's button then names your choice, such as "Ask DeepSeek for a fix".

Your key belongs to your account in this organization. Zof stores it encrypted and reads return only its last four characters. Under Advanced, click Replace API key to change it, or Remove API key, then confirm Remove key. Replacing or removing a key stops active fixes using it at their next model request. Removing your default key resets future fixes to Codex; start another fix with Codex or a working personal key. After an admin turns its provider off, you can still remove it; outstanding attempts cannot make further requests with the old key. Demo mode has no personal-key controls.

A fix uses no Zof credits, but your company needs a plan or credits left, and no payment overdue past its 7-day grace. While usage charging is off, it needs run credits left instead. If not, the drawer says what to do. Each provider sends repository code and failure evidence to its vendor, which bills your API account; the drawer shows this notice. DeepSeek and Kimi run in the same Claude Code agent as Claude, with the same tools and checks. If the key is invalid, your credits are exhausted, or a usage limit is reached, the drawer explains what to do. Your default fix provider saves a ready selection for future fixes. A missing-key selection is saved only after your key is saved successfully. If saving the default fails, check the key and retry before starting a fix. Use Codex saves Codex as your default; it requires another explicit request. Zof never silently switches providers. An active attempt keeps the provider and personal key it started with.

The drawer, progress and result identify the provider that actually ran. Every provider uses the same patch checks, sandbox validation, downloads and draft pull request. If a saved provider is blocked or unavailable, it stays visible and cannot start a fix. Check its key or explicitly choose another provider.

While the fix runs

Once the fix has started, track it through Queued, Working on the fix, and Saving the result. Stages advance when confirmed. Keep the panel open until the pull request appears: if you close it first, the fix keeps running, and you click Open pull request when you come back. Reconnecting retries updates. If updates pause, Check status resumes them without starting another fix.

What Codex gives you

To apply a downloaded patch, use git apply on the commit the diff names, review it and run your tests like any other change.

Pull requests for fixes

The separate Zof Fix App opens a draft pull request with the fix, through Zof, for you to review and merge on GitHub. PR fixes target the original PR's head branch. Test runs use their saved branch when available; manual reviews and runs without a saved branch use the verified branch you selected. Zof checks that branch again when the fix starts and before publication. Older fixes without a verified target remain downloadable; choose Write another fix to resolve a target.

Members, company admins, and custom roles granted fix access can request fixes and open fix pull requests. Built-in viewers remain read-only. Opening a pull request also needs your own GitHub account linked and permission to push to that repository.

When the Fix App isn't ready, the drawer says so in one line before any fix starts, with what to do. Ask Codex for a fix still gets you a patch to download. The Connection tab of the GitHub page shows the full Fix pull requests setup once GitHub is connected. If the Fix App is missing, suspended, or needs Contents: write and Pull requests: write, a GitHub organization owner installs it, resumes it, or accepts the permission update on GitHub. This approval is once per installation; permitted members do not need to become organization owners. Use Install Zof Fix App on GitHub, or Manage Zof Fix App on GitHub once it's installed. GitHub opens in a new tab, and the drawer checks again when you come back. On the Connection tab, use Refresh Fix App status: it checks setup and never publishes a fix. If GitHub reports a publication permission error even though setup is ready, ask the owner to check that the Fix App installation includes this repository.

Setup describes the recorded installation permissions. Zof checks repository coverage, your GitHub access, publication authorization, and validation again when it opens the pull request. A setup check failure keeps publication unavailable; you can still download the patch.

Once it is live:

1. When a fix you just started is ready, Zof opens the pull request by itself and the panel says "Opening the pull request…". Asking for the fix is your request: there is no other button or checkbox. A saved fix, or one from Write another fix, waits until you click Open pull request, so only the patch you choose gets a pull request.
2. Opening it pushes a branch with the patch to your repository, and the repository's CI may run on that branch with its secrets. A draft pull request doesn't stop CI.
3. The panel then links "Pull request #N ↗", marked draft: Zof opens fix pull requests as drafts only. Reopening the panel shows the same link. Review the change on GitHub before you merge it.
4. If the panel says "Zof is checking whether the pull request was opened. This can take a few minutes.", wait: the panel keeps checking, and offers no new request until Zof knows.
5. Zof waits while setup is unconfirmed and while the sandbox tests the patch. It opens nothing when your tests failed with the patch, when the patch doesn't apply, or when the source branch has changed since the fix was written. On the compatible deployment, Zof checks your current fix grant and company switch at publication and before each GitHub write permit. If it cannot check access, publication waits. If it reports revoked authorization, review the patch and use Retry once your access is restored.
6. For a fix you just started, Zof tries once while the panel is open. If the request is refused, the panel says why, and offers Retry when trying again can help. You can still download the patch.

Zof's sandbox will also run your tests with the patch. While it does, the panel says "Testing the patch in the sandbox…", then "Your tests passed with this patch." or "Your tests failed with this patch.". Until the sandbox runs, the panel says "Not tested yet", with the reason when there is one. Write another fix waits until the test is done: "You can write another fix once the patch has been tested."

An untested patch is subject to Zof's current publication policy. Setup readiness does not confirm that policy. If Zof has not accepted a passed sandbox validation for the patch, wait for validation and retry, or write another fix.

Check that it worked

1. The panel says "Codex proposed a fix" and lists the files.
2. The panel links "Pull request #N ↗", marked draft, and the draft is on GitHub.
3. If you downloaded the patch instead, git apply --check passes on that commit.

If something goes wrong