Menu
How to run tests using remote executor.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Optimize slow Rust test workflows in Codewith codex-rs. Use when tests feel slow, compile/link dominates execution, app-server integration tests are filtered but still build huge binaries, or when deciding local/CI test strategy, target dirs, nextest filters, or Codewith skill guidance for test speed.
Use when the user asks to merge a GitHub PR, merge when green, enable auto-merge, add to a merge queue, or decide whether a PR is mergeable. Do not use for ordinary PR review unless there is explicit merge intent.
Route and verify development work in the hasna/codewith fork across Rust runtime, provider/model/auth/profile behavior, TUI, app-server protocol, MCP lifecycle, goals/native loops, upstream merges, and release gates. Use when implementing, debugging, reviewing, or shipping work in any of these Codewith runtime domains, especially changes that cross crates or user-facing surfaces and need the correct project skills, focused tests, snapshots, schemas, or fork-preservation checks.
Build, format, lint, and test Codewith Rust crates in codex-rs. Use when making or verifying Rust changes, resolving Codewith build errors, updating Cargo or Bazel locks, building release binaries, or validating Rust before npm publish.
Diagnose and safely repair Codewith config.toml and MCP startup failures. Use only when the user explicitly starts the self-heal workflow or asks to fix Codewith configuration/MCP breakage.
Update the title and body of one or more pull requests.
| name | remote-tests |
| description | How to run tests using remote executor. |
Some Codewith integration tests support a running against a remote executor. This means that when CODEX_TEST_REMOTE_ENV environment variable is set they will attempt to start an executor process in a docker container CODEX_TEST_REMOTE_ENV points to and use it in tests.
Docker container is built and initialized via ./scripts/test-remote-env.sh
Currently running remote tests is only supported on Linux, so you need to use a devbox to run them
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.
