MCP.Market

remote-tests skill

by openinterpreter·openinterpreter/openinterpreter·69k stars·Apache-2.0

Testing against remote executors in integration tests.

A100/100content scan

Is the remote-tests skill safe?

Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-10-25.

No findings.

Install the remote-tests skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/openinterpreter/openinterpreter.git /tmp/openinterpreter
mkdir -p ~/.claude/skills
cp -r /tmp/openinterpreter/.codex/skills/remote-tests ~/.claude/skills/remote-tests
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

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::buildwithauto_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::newwithautoenv() unless the test defines its own $CODEXHOME/environments.toml or will define custom environments at runtime.

Start threads with TestAppServer::sendthreadstartrequestwithautoenv() 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:

  • skipiftarget_windows!: Windows target behavior.
  • skipifwine_exec!: Wine-exec runner constraints.
  • skipifhost_windows!: Windows host constraints.
  • skipifremote!: Local-only test behavior.
  • skipifnoremoteenv!: 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 codexremoteenv_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 . 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.

More skills from openinterpreter/openinterpreter

  • Ababysit-prBabysit 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.
  • Acode-breaking-changesBreaking changes
  • Acode-reviewRun a final code review on a pull request
  • Acode-review-change-sizeChange size guidance (800 lines)
  • Acode-review-contextModel visible context
  • Acode-review-testingTest authoring guidance
  • Acodex-pr-bodyUpdate the title and body of one or more pull requests.
  • AimagegenGenerate or edit raster images when the task benefits from AI-created bitmap visuals such as photos, illustrations, textures, sprites, mockups, or transparent-background cutouts. Use when Codex should create a brand-new image, transform an existing image, or derive visual variants from references, and the output should be a bitmap asset rather than repo-native code or vector. Do not use when the task is better handled by editing existing SVG/vector/code-native assets, extending an established icon or logo system, or building the visual directly in HTML/CSS/canvas.
  • Aopenai-docsUse for Codex models/pricing, scheduled tasks, skills, settings, setup, troubleshooting, customization, automations, and self-knowledge—including 'you,' 'your,' 'this app,' or 'this coding agent' when they refer to Codex—and for OpenAI APIs/products and ChatGPT Work. Also use for model choice/migration, prompting, SDKs, Responses, Realtime, agents, evals, and Chat/Work/Codex comparisons. Do not use for generic app/software tasks that merely mention Codex.
  • Apath-typesChoose Rust types for operating system paths across the Codex repository. Use when defining new path-bearing types or explicitly migrating existing ones.
  • Dplugin-creatorCreate 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.
  • Aqa-testingVerify your work by actually operating the app or website you changed, instead of assuming it works. Strongly recommended whenever you build, modify, or debug a web app, website, or desktop GUI app. Drive real browsers with the agent-browser CLI and native desktop apps with the cua-driver CLI. These are installed on demand through the host's normal command-approval flow.

All agent skills → · MCP servers