Menü
How to run tests using remote executor.
Create and scaffold plugin directories for Codex with a required `.codex-plugin/plugin.json`, optional plugin folders/files, valid manifest defaults, and personal-marketplace entries by default. Use when Codex needs to create a new personal plugin, add optional plugin structure, generate or update marketplace entries for plugin ordering and availability metadata, or update an existing local plugin during development with the CLI-driven cachebuster and reinstall flow.
Choose Rust types for operating system paths across the Codex repository. Use when defining new path-bearing types or explicitly migrating existing ones.
Babysit a GitHub pull request after creation by continuously polling review comments, CI checks/workflow runs, and mergeability state until the PR is merged/closed or user help is required. Diagnose failures, retry likely flaky failures up to 3 times, auto-fix/push branch-related issues when appropriate, and keep watching open PRs so fresh review feedback is surfaced promptly. Use when the user asks Codex to monitor a PR, watch CI, handle review comments, or keep an eye on failures and feedback on an open PR.
Pushing GitHub Actions changes, resolving push rejection, requesting upload exceptions.
Update the title and body of one or more pull requests.
Use when the user asks how to build with OpenAI products or APIs, asks about Codex itself or choosing Codex surfaces, needs up-to-date official documentation with citations, help choosing the latest model for a use case, or model upgrade and prompt-upgrade guidance; use OpenAI docs MCP tools for non-Codex docs questions, use the Codex manual helper first for broad Codex self-knowledge, and restrict fallback browsing to official OpenAI domains.
| name | remote-tests |
| description | How to run tests using remote executor. |
Some Codex integration tests select local, docker, or wine-exec through
CODEX_TEST_ENVIRONMENT. The legacy CODEX_TEST_REMOTE_ENV=<container> still
selects Docker; otherwise execution is local.
Docker container is built and initialized via ./scripts/test-remote-env.sh
On x86-64 Linux, run Wine exec with
bazel test //codex-rs/core:core-all-wine-exec-test --test_output=errors.
Temporary blockers belong beside the test in skip_if_wine_exec! calls.
You can list devboxes via applied_devbox ls, pick the one with codex in the name.
Connect to devbox via ssh <devbox_name>.
Reuse the same checkout of codex in ~/code/codex. Reset files if needed. Multiple checkouts take longer to build and take up more space.
Check whether the SHA and modified files are in sync between remote and local.
