Skip to content
cccskills
FreePublished on GitHub

remote-tests

Test agent features across local and remote execution environments using integration tests, which check components working together. Covers Docker and Wine setups, test helpers, and configuration-specific skips for the app-server and exec-server split.

OriginalShow the original description

Testing against remote executors in integration tests.

Works withDocker
See how to install

Good for

  • Run core integration tests with a Docker remote executor
  • Test a Windows exec-server under Wine
  • Adapt app-server tests for remote execution
  • Skip tests for specific environment constraints

Files included (1)

  • SKILL.md3.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Remote executor tests exercise the app-server/exec-server split to ensure that agent features work in both local and remote execution environments.

Remote executor tests currently require an x86_64 Linux host machine. There are two flavors:

  1. Docker (Linux exec-server)
  2. Wine (Windows exec-server)

Test Fixtures

Individual test cases must opt-in to being run against a remote executor.

codex_core

Use TestCodexBuilder::build_with_auto_env() to opt-in to remote execution in core integration tests unless the test needs more precise control over its executor.

app-server

Start the server with TestAppServer::new_with_auto_env() unless the test defines its own $CODEX_HOME/environments.toml or will define custom environments at runtime.

Start threads with TestAppServer::send_thread_start_request_with_auto_env() if you've created the server with the auto_env approach. Omit ThreadStartParams.environments (leave it as None) when doing so.

Test Skips

If a test doesn't pass in a particular remote executor configuration you can skip it in just that configuration. Include a string reason for future readers when the selected skip macro supports one.

Choose the skip macro by what causes the test to fail:

  • skip_if_target_windows!: Windows target behavior.
  • skip_if_wine_exec!: Wine-exec runner constraints.
  • skip_if_host_windows!: Windows host constraints.
  • skip_if_remote!: Local-only test behavior.
  • skip_if_no_remote_env!: Remote-only test behavior.

Prefer defining tests that run in all host/target configurations by default. See the $path-types skill for the most common changes required to make tests compatible.

Docker

Docker container is built and initialized via ./scripts/test-remote-env.sh. Sourcing this script in bash also provides the codex_remote_env_cleanup function to use after testing.

To run core integration tests against a Docker remote executor:

bash -c '
  set -euo pipefail
  unset CODEX_TEST_REMOTE_EXEC_SERVER_URL
  source scripts/test-remote-env.sh
  trap codex_remote_env_cleanup EXIT

  cd codex-rs
  just test -p codex-core --test all
'

To run app-server integration tests against a Docker remote executor:

bash -c '
  set -euo pipefail
  unset CODEX_TEST_REMOTE_EXEC_SERVER_URL
  source scripts/test-remote-env.sh
  trap codex_remote_env_cleanup EXIT

  cd codex-rs
  just test -p codex-app-server --test all
'

Wine

These tests build an exec-server for Windows and run it under Wine, with the app-server staying on the Linux host. The cross-platform build dependency means they only run in Bazel.

For core integration tests:

bazel test //codex-rs/core:core-all-wine-exec-test

For app-server integration tests:

bazel test //codex-rs/app-server:app-server-all-wine-exec-test

Devboxes

You can use a devbox to run these tests if you are running on a macOS machine.

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.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

babysit-pr

FreeSummary

Monitor a GitHub pull request for review feedback, automated check failures, and merge readiness. Diagnose failures, fix problems caused by the branch, and retry likely temporary failures while continuing to watch for updates.

  • Monitor automated checks after opening a pull request
  • Address actionable review feedback
  • Distinguish code failures from temporary service problems
openinterpreter/openinterpreter68.6KUpdated Oct 11, 2026

Review external integration points for breaking changes that could disrupt existing use. Examine app-server APIs, command-line parameters, configuration loading, and session resumption from saved records, continuing beyond the first issue to cover possible failure paths.

  • Check app-server API compatibility
  • Review changes to command-line parameters
  • Check compatibility of configuration loading
openinterpreter/openinterpreter68.6KUpdated Oct 11, 2026

code-review

FreeSummary

Run a final pull request review using separate agents for each available review skill. Collect all reported issues into a numbered Markdown list, with a specific file path and line number for every finding.

  • Run a final review of a pull request
  • Combine findings from multiple review skills
  • Locate issues by file path and line number
openinterpreter/openinterpreter68.6KUpdated Oct 11, 2026

Assess whether a code change is small enough to review using line-count guidance. For larger changes, examine the actual differences, dependencies, and calling code to suggest reviewable stages and the smallest coherent first step.

  • Check the size of a change before requesting review
  • Assess the scope of a complex logic change
  • Plan reviewable stages for a large change
openinterpreter/openinterpreter68.6KUpdated Oct 11, 2026

Review code that manages the conversation history and extra information sent to Codex models. Apply rules for incremental history, size limits, cache stability, manual review of large additions, and required implementation structures.

  • Review changes to conversation history handling
  • Check size limits on information sent to the model
  • Identify large additions requiring manual review
openinterpreter/openinterpreter68.6KUpdated Oct 11, 2026

Plan and write tests for changes to agent behavior, favoring integration tests that check components together. Identify key logic changes and user-visible behavior to cover, reuse existing helpers, and keep unit tests in dedicated files.

  • Identify test coverage for changes to agent logic
  • Add integration tests for user-visible behavior
  • Organize unit tests in dedicated files
openinterpreter/openinterpreter68.6KUpdated Oct 11, 2026

See all skills by openinterpreter

Report a problem with this skill