### Motivation When Codex is launched from a region where Cloudflare blocks access (for example, Russia), the CLI currently dumps Cloudflare’s entire HTML error page. This isn’t actionable and makes it hard for users to understand what happened. We want to detect the Cloudflare block and show a concise, user-friendly explanation instead. ### What Changed - Added CLOUDFLARE_BLOCKED_MESSAGE and a friendly_message() helper to UnexpectedResponseError. Whenever we see a 403 whose body contains the Cloudflare block notice, we now emit a single-line message (Access blocked by Cloudflare…) while preserving the HTTP status and request id. All other responses keep the original behaviour. - Added two focused unit tests: - unexpected_status_cloudflare_html_is_simplified ensures the Cloudflare HTML case yields the friendly message. - unexpected_status_non_html_is_unchanged confirms plain-text 403s still return the raw body. ### Testing - cargo build -p codex-cli - cargo test -p codex-core - just fix -p codex-core - cargo test --all-features --------- Co-authored-by: Eric Traut <etraut@openai.com>
codex-core
This crate implements the business logic for Codex. It is designed to be used by the various Codex UIs written in Rust.
Dependencies
Note that codex-core makes some assumptions about certain helper utilities being available in the environment. Currently, this support matrix is:
macOS
Expects /usr/bin/sandbox-exec to be present.
Linux
Expects the binary containing codex-core to run the equivalent of codex sandbox linux (legacy alias: codex debug landlock) when arg0 is codex-linux-sandbox. See the codex-arg0 crate for details.
All Platforms
Expects the binary containing codex-core to simulate the virtual apply_patch CLI when arg1 is --codex-run-as-apply-patch. See the codex-arg0 crate for details.