Codex Was Autonomously Building Our Salesforce 2GP App. Then It Found a Platform Bug and Filed the Ticket Itself.

At 8:57 AM on August 26, 2026, Salesforce emailed me to say that Case #474463909 was open. At 8:46 AM the next morning, Salesforce Support replied that several partners were experiencing the same issue and that Salesforce had logged it internally as a bug.

I did not write the case. I did not collect the reproduction steps. I did not spend the night reconstructing every OAuth setting we had tested. Codex had already done all of it while building the Salesforce version of ApexGenius.

Codex encountered the blocker, investigated it, ruled out our configuration, inspected Salesforce's request, respected the security boundary, documented the evidence, and escalated the issue to the vendor.

The autonomous package build

The job was concrete: create the new managed second-generation package lineage for ApexGenius in the registered agai namespace. This is the supported distribution path for installing and upgrading the app in subscriber Salesforce orgs.

Before Salesforce can create a namespaced managed 2GP package, the Dev Hub has to link to the org that owns the registered namespace. Codex reached that release gate and ran Salesforce's Link Namespace flow. The authorization handoff failed with one persistent error:

error=invalid_request&error_description=missing required code challenge

That error did not point to Apex, Lightning Web Components, package metadata, or a dependency in our source. It happened before package creation, inside the OAuth exchange that Salesforce uses to connect the two orgs.

What Codex ruled out first

A useful investigation starts by making the common explanations fail. Codex rebuilt the connected app using Salesforce's documented workaround, corrected the callback URLs for both enhanced-domain variants, and waited through the propagation windows that make connected-app debugging especially frustrating.

That work cleared the earlier client ID and redirect URI failures one by one. The same PKCE error remained. This mattered because it moved the investigation away from our connected-app configuration and onto the request Salesforce was generating.

The request Salesforce generated was missing PKCE

Codex inspected the actual authorization request created by the namespace linker. The destination required Proof Key for Code Exchange, but the request did not include either of the parameters required to begin that exchange:

• code_challenge
• code_challenge_method

Salesforce was rejecting a request created by its own namespace-linking page because that request omitted the security parameters the platform required. At that point the evidence matched the error exactly. This was no longer a theory based on a generic OAuth message.

The security boundary was part of the engineering

The remaining workaround involved disabling PKCE on the SalesforceDX Namespace Registry connected app from the Dev Hub side. That control was platform-enforced and unavailable to us in Setup.

Codex recognized the boundary. It did not attempt to bypass the platform control, weaken another connected app, or invent an unsupported route around Salesforce's security policy. It turned the investigation into a vendor escalation with a narrowly defined request for the team that owned the control.

The case Codex filed

The support case gave Salesforce a runnable starting point instead of a vague report that namespace linking was broken. It included both org IDs, the registered namespace, five exact reproduction steps, the full error, the connected-app configuration already tested, and the action Salesforce Support needed to take.

Salesforce confirmed the bug the next morning

Salesforce Support responded at 8:46 AM on August 27. The engineer said several partners were facing the same issue, Salesforce had logged it as a bug, and Support needed to disable PKCE on the SalesforceDX Namespace Registry connected app as the workaround.

What to send Salesforce if your namespace link fails

If your managed 2GP work stops at the same error, capture the evidence before changing more configuration. A useful case should include:

1. The 18-character org IDs for the Dev Hub and namespace org.
2. The registered namespace prefix.
3. The exact Link Namespace steps that reproduce the failure.
4. The full OAuth error, including its query-string parameters.
5. The callback URLs and connected-app changes already tested.
6. A request for Salesforce Support to review the SalesforceDX Namespace Registry connected app and the enforced PKCE setting.

Keep credentials, access tokens, usernames, and private org details out of public posts. Send the complete values only through the authenticated Salesforce support case.

The package is blocked, but the release is not lost

The managed package still depends on Salesforce completing the platform-side action. That is frustrating, but it is a bounded dependency now. We know the package source is not the cause. We know which team owns the next step. Work that does not depend on the final namespace link can continue without pretending the blocker is solved.

That distinction matters in release engineering. A blocker without evidence can consume every workstream. A blocker with a reproduced cause, an owner, and an escalation path becomes one item on the release plan.

The bigger lesson is the complete engineering loop

The interesting part of this story is not that an AI agent recognized an OAuth error. The useful part is that Codex participated in the entire engineering process. It attempted the build, tested the normal fixes, inspected the failing request, established the ownership boundary, documented the evidence, and filed the escalation.

This is how powerful AI-native engineering becomes when autonomous agents can run the complete loop. Code generation is one step. The leverage arrives when the agent can keep moving through diagnosis, verification, documentation, and vendor coordination while preserving the same security and release controls a strong human engineer would use.

Frequently asked questions