Codex Cloud fails at “Downloading repo” before agent execution, including with Automatic setup

What issue are you seeing?

Summary

Codex Cloud repeatedly fails to initialize an environment for a private GitHub repository. Tasks fail before agent commands appear. The environment editor’s interactive test reproduces the same visible failure.

Observed September 9, 2026, using ChatGPT Pro, Chrome on Windows, and the universal environment image.

What steps can reproduce the bug?

Steps to reproduce in the affected environment

1. Select the existing private repository environment and an existing branch.
2. Submit a repository-backed task.
3. Observe “Downloading repo,” followed by “Failed to set up container.”
4. Alternatively, open Edit environment and select Connect interactive terminal.

What is the expected behavior?

Expected behavior

Repository checkout completes and setup proceeds, or an actionable underlying checkout error is provided.

Additional information

Troubleshooting performed

• Both assisted submission and direct manual submission reproduce the failure.
• The original manual setup failed.
• A separate unsaved diagnostic configuration with only setup markers and read-only Git commands also failed; no marker appeared.
• The existing environment was changed to Automatic setup and saved. An interactive test still failed.
• Container caching is off.
• The GitHub App installation is active, with all-repository access and read/write code and pull-request permissions.
• No pending permission approval is visible.
• Separate authenticated GitHub API reads succeed.
• Current main contains approximately 12,100 files and 1.06 GB of tracked contents. This is not measured clone traffic or evidence of a platform limit.
• No repository-configured LFS filters or submodules were found in current main.

Scope and limitations

This report concerns startup before implementation, not context exhaustion or final diff extraction.

The affected repository is private. This is a reproduction in our environment, not yet a public minimal reproducer. We have not yet completed a tiny-repository control test.

Private task IDs, environment ID, and additional diagnostic metadata can be supplied to OpenAI Support. Repository contents, credentials, account identifiers, and raw authentication/network logs are intentionally omitted.

Related reports

• Similar startup symptom: https://github.com/openai/codex/issues/1648
• Matching community discussion: https://community.openai.com/t/getting-generic-failed-to-set-up-container-error/1266173

These reports establish similar symptoms, not a confirmed shared cause.

Could the team expose or inspect the underlying repository-download error and clarify whether this is an authorization, checkout, resource, or service-side failure?

Start by reproducing the failure through the existing private repository environment and the Edit environment interactive terminal path. Compare the repository-download and container-setup stages, then consider the issue done when checkout succeeds or the underlying authorization, checkout, resource, or service-side error is exposed; a tiny-repository control test is still outstanding.