You pick an org repo in Codex cloud and get unable to clone or Repository not found. The repo is right there in your browser when you log into GitHub, but Codex can’t see it. This is almost always a GitHub App permission problem, not a Codex bug.
Fastest fix (covers ~80% of cases): open https://github.com/settings/installations, confirm the ChatGPT Codex Connector App (published by OpenAI) is installed on the org that owns the repo, then open its config and make sure the repo is checked under Repository access. Wait ~30 seconds, then re-pick the repo in Codex. If the org enforces SAML, you also have to authorize the App for SSO (Step 4). Steps below in priority order.
The App is literally named “ChatGPT Codex Connector” — that’s what you’re looking for in the installations list, not the word “Codex” on its own. Codex needs three independent GitHub permission layers to all line up: your user OAuth grant, the App installation on the org, and the App’s repository selection. Most failures are one missing checkbox in one of those layers.
Which bucket are you in?
| Symptom | Most likely cause | Jump to |
|---|---|---|
| Org doesn’t appear in Codex repo picker at all | Codex App never installed on that org | Step 1 |
| Org shows, but this one repo is missing | Repo not in “Only select repositories” allowlist | Step 2 |
Was working, suddenly Repository not found | User OAuth / SSO grant lapsed | Step 3 |
| Enterprise org, repo invisible even after install | SAML SSO not authorized for the App | Step 4 |
submodule update failed (not clone failed) | Submodule repo outside granted scope | Step 5 |
| Brand-new repo with no commits fails to clone | Empty repo has no default branch yet | See “Empty repo” note |
| You see the org but zero repos inside | EMU org — an org owner must install the App | Step 1 (admin) |
Common causes, highest hit rate first
1. Codex Connector App not installed on the org
You authorized Codex on your personal account, but the repo lives under acme-corp. The App needs a separate installation on every org you want Codex to see.
How to spot it: Visit https://github.com/organizations/acme-corp/settings/installations. If ChatGPT Codex Connector isn’t listed, that’s the problem.
2. Repo not in the App’s “Repository access” allowlist
The App is installed on the org but configured with Only select repositories, and this specific repo isn’t checked. Common right after creating a new repo — GitHub does not auto-add new repos to a “selected” allowlist.
How to spot it: Open the Codex installation page and look at Repository access. If it reads Only select repositories (N) and your repo isn’t in the list, check it.
3. User OAuth or SSO grant lapsed
The user-level grant (separate from the App install) expires on your org’s SSO session policy. After it lapses, Codex acts as “unauthenticated” against that org even though the App is still installed, and a repo that worked yesterday returns Repository not found.
How to spot it: Disconnect and reconnect GitHub in Codex. If orgs or repos that were missing suddenly appear, your grant was stale.
4. SAML SSO not authorized for the App
Enterprise orgs that enforce SAML require each user to authorize the App against an active SSO session. Per GitHub’s docs, if your org uses SSO and you can’t see its resources after authorizing a GitHub App, you have to reauthorize the app after starting a fresh SSO session for that org. Until you do, the repo is invisible to Codex.
How to spot it: In the org’s Settings → Third-party Access → GitHub Apps (click your profile → Your organizations → the org → Settings, then under “Third-party Access” in the sidebar), look for Codex with an SSO grant that needs authorizing. An org owner may have to allow the App first.
5. Submodule outside the granted scope
Codex clones the repo fine, but the task references a submodule pointing at a different private repo that Codex can’t reach. The error reads submodule update failed, not clone failed.
How to spot it: Re-read the exact error string. Submodule failures are distinct from top-level clone failures.
6. EMU / Enterprise Managed Users org
For orgs using Enterprise Managed Users (EMU), an organization owner must install the ChatGPT Codex Connector App for the org before any member can connect repos in Codex cloud. As of June 2026 a regular member can’t self-install — you’ll see the org but no repos inside.
How to spot it: Public repos in the org would be visible to a normal token, but Codex shows the org with an empty repo list and no “Configure” option you can act on. Ask an org owner to install Codex.
Plan note (not usually the cause). As of June 2026, Codex — including cloud tasks — is included on every ChatGPT tier: Free, Go, Plus, Pro, Business, Edu, and Enterprise. (This changed from earlier in the product’s life, when cloud was Plus-and-up.) Cloud tasks draw from your plan’s included limits and burn them faster than local runs, and Free is tightly capped. So if a task won’t start because you’ve hit a usage limit, that looks different from a permission error: you’ll get a quota/limit message, not
unable to cloneorRepository not found. If you’re seeing the clone/not-found errors, it’s a permission layer below, not your plan.
Shortest path to fix
Ordered by ROI. Steps 1–3 fix the most common case (org install missing or scoped wrong).
Step 1: Verify the App is installed on the right org
Go to:
https://github.com/settings/installationsThis lists every org/account that has the ChatGPT Codex Connector installed. If the target org isn’t there:
- Click Configure on an existing install, or open
https://github.com/apps/chatgpt-codex-connectorand click Install. - Choose the org that owns your repo.
- Approve the install.
If you’re not an org owner, an admin has to approve. Send them https://github.com/apps/chatgpt-codex-connector — they get a one-click Install button (or a Request button if the org restricts App installs). For EMU orgs, only an org owner can complete this.
Step 2: Add the specific repo to “Repository access”
Once installed, open the Codex install for that org and scroll to Repository access:
○ All repositories
● Only select repositories
[ ] acme-corp/marketing-site
[x] acme-corp/api-server ← needs this checkbox
[ ] acme-corp/internal-toolsTick the repo, click Save. Wait ~30 seconds for GitHub to propagate, then retry in Codex.
For teams that frequently add repos, switch to All repositories to skip the per-repo checkbox dance, at the cost of broader access.
Step 3: Re-run the OAuth / SSO grant
Even if the App is correct, your user grant might be stale. In Codex:
- Settings → Connected accounts → GitHub → Disconnect.
- Reconnect. This triggers a fresh OAuth grant (and a SAML grant if your org enforces SSO).
- Watch for the SAML org consent screen on enterprise SSO — it often opens in a popup and is easy to miss or have blocked by a popup blocker.
Step 4: Authorize SAML SSO (enterprise only)
If your org enforces SAML, the App install alone isn’t enough. Visit:
https://github.com/orgs/acme-corp/sso?return_to=%2Fsettings%2FinstallationsAuthorize against your org’s identity provider. This creates the SSO grant Codex needs to act on the org with your token. You need an active SSO session at the moment you authorize — if you authorized weeks ago and the session expired, redo it.
Step 5: For submodules, grant the submodule repo too
If the error is submodule update failed, the submodule lives in another repo. Add that repo to Codex separately:
# inspect submodule URLs
git config --file .gitmodules --get-regexp url
# example output:
# submodule.shared-types.url git@github.com:acme-corp/shared-types.gitAdd acme-corp/shared-types to the same Codex install (or to a new install if the submodule lives in a different org).
Step 6: Quick unblock — clone with a fine-grained PAT in the setup script
If you can’t get App permissions sorted right now and just need the task to run, generate a fine-grained Personal Access Token scoped to the repo and add it as a Secret in your Codex environment:
GitHub → Settings → Developer settings → Personal access tokens → Fine-grained tokens
Repository access: Only select repositories → [your repo]
Permissions: Contents (read), Metadata (read) # add Pull requests (read/write) if Codex opens PRsAdd it to your Codex Environment as a Secret named GITHUB_TOKEN. Then clone with the token inside the setup script:
git clone https://x-access-token:$GITHUB_TOKEN@github.com/acme-corp/api-server.gitImportant: in Codex cloud, Secrets are only decrypted for task execution and are removed before the agent phase runs (by design, so the agent can’t leak credentials into output or generated code). Environment variables, by contrast, stay set for the full task including the agent phase — but don’t put a raw token in a plain variable, since the agent can read it. So clone in the setup script while the secret still exists; if the agent later needs to push or fetch, configure a git credential helper during setup (for example write the token into ~/.git-credentials and run git config --global credential.helper store) so the already-cloned working copy stays authenticated without exposing $GITHUB_TOKEN to the agent. Use a PAT only as a stopgap — an App install is the durable, auditable answer.
Empty repo note
A brand-new repo with no commits has no default branch, and Codex will fail to clone it even with correct permissions. Push a first commit, then retry:
git commit --allow-empty -m "chore: initialize repo" && git push origin mainHow to confirm it’s fixed
- In the Codex repo picker, the org and repo now both appear and are selectable.
- Start a task — the run log shows the container checking out your branch/SHA without a
clone failedline. - If you used Step 6, the setup-script log shows the clone succeeding and the agent phase starting with the repo already on disk.
If the picker still hides the repo after a successful install + allowlist + SSO grant, the propagation cache is the usual culprit — give it a minute and reload, or disconnect/reconnect GitHub once to force a refresh.
Prevention
- When creating a new repo, add it to Codex’s access list immediately — bake it into your repo-creation checklist.
- For active teams, set Codex to All repositories on the org so new repos auto-include without manual ticking.
- Re-run the Codex OAuth/SSO grant when your SSO session policy is short; a calendar reminder helps.
- Document the SAML SSO authorize step in onboarding — every enterprise dev hits it once.
- For monorepos with submodules, grant Codex to every submodule org up front.
- Avoid long-lived PATs as primary auth — they leak more easily than App installs and don’t show in the App audit log.
FAQ
Why does the repo show in my browser but not in Codex? Your browser session and Codex use different permission paths. The browser uses your logged-in user account; Codex uses the GitHub App installation plus your OAuth/SSO grant. The repo can be fully visible to you while the App has no access to it. Check the App install (Step 1) and its repository allowlist (Step 2).
Do I need a paid plan for Codex to clone private repos?
No. As of June 2026 Codex (cloud tasks included) ships on every ChatGPT tier — Free, Go, Plus, Pro, Business, Edu, and Enterprise. A plan only limits how much you can run: cloud tasks draw from your included usage and Free is tightly capped. Hitting that cap shows up as a usage/limit message, not unable to clone or Repository not found, so the clone errors here are permission problems, not plan problems.
I’m an org member, not an owner — why can’t I install Codex?
On many orgs, especially Enterprise Managed Users (EMU), only an org owner can install or approve a GitHub App. Send an owner the install link https://github.com/apps/chatgpt-codex-connector; they install it for the org, then your repos appear.
The clone worked yesterday and now says Repository not found. What changed?
Almost always your SSO session or OAuth grant expired (Step 3), or the repo was moved/renamed/made private under a different App scope. Disconnect and reconnect GitHub in Codex, and re-authorize SSO if your org enforces it (Step 4).
My PAT works locally but Codex still can’t clone. Why?
In Codex cloud, Secrets (including a GITHUB_TOKEN PAT) are available only to the setup script and are stripped before the agent runs. Do the authenticated git clone or set up a credential helper in the setup script, not in the task prompt.
My fix isn’t taking effect on re-run. Codex caches container state for up to ~12 hours and reuses it. Per the Codex cloud docs, the cache is invalidated automatically when you change the setup script, maintenance script, environment variables, or secrets — but a pure permission change on GitHub may not invalidate it. After fixing GitHub access, open the environment’s settings page and click Reset cache (or change something in the setup script) to force a clean checkout on the next run. On Business/Enterprise the cache is shared across everyone with access to the environment, so a teammate’s stale run can mask your fix.