remote-tests

remote-tests — официальный workflow Codex для интеграционных тестов, в которых app-server и exec-server работают раздельно, а выполнение проверяется на удалённом executor. Источник прямо ограничивает текущую схему хостом x86_64 Linux. Описаны два варианта удалённого исполнения: Docker с Linux exec-server и Wine с Windows exec-server. Такой набор нужен, когда важно проверить не только локальный путь, но и взаимодействие агентных функций с отдельным исполнительным процессом и разными целевыми окружениями. Карточка описывает подготовку и маршрутизацию тестов; она не утверждает, что тесты уже прошли в конкретном проекте или на конкретной машине. Тесты должны явно выбирать удалённый executor, если это требуется сценарию. Для интеграций codex_core источник рекомендует TestCodexBuilder::build_with_auto_env(), кроме случаев, где тесту нужен более точный контроль над executor. Для app-server используется TestAppServer::new_with_auto_env(), если тест не задаёт собственный $CODEX_HOME/environments.toml или не создаёт окружения во время выполнения. После создания сервера можно стартовать thread через TestAppServer::send_thread_start_request_with_auto_env(); при auto_env параметр ThreadStartParams.environments нужно оставить None. Эти правила связывают fixture с автоматически подготовленным окружением и не позволяют незаметно смешать его с ручной конфигурацией. Если проверка не проходит в одной конфигурации executor, источник предлагает выбирать skip-макрос по фактической причине и оставлять строковое объяснение для будущих читателей, когда это поддерживает выбранный макрос. skip_if_target_windows! относится к поведению Windows target, skip_if_wine_exec! — к Wine exec runner, skip_if_host_windows! — к Windows host, skip_if_remote! — к local-only поведению, а skip_if_no_remote_env! — к remote-only сценарию. По умолчанию предпочтительны тесты, работающие во всех host/target конфигурациях; макросы нужны для документированного ограничения, а не для сокрытия нестабильности. Источник отдельно направляет к $path-types для типичных изменений, делающих тест совместимым с несколькими конфигурациями. Docker-сценарий поднимается и инициализируется скриптом ./scripts/test-remote-env.sh. В shell-примере сначала снимается CODEX_TEST_REMOTE_EXEC_SERVER_URL, затем скрипт source-ится, функция codex_remote_env_cleanup регистрируется через trap, после чего внутри каталога codex-rs запускается just test -p codex-core --test all или just test -p codex-app-server --test all. Cleanup важен для удаления созданного окружения после проверки. Wine-путь требует сборки Windows exec-server под Wine, пока app-server остаётся на Linux host; эти тесты запускаются через Bazel target //codex-rs/core:core-all-wine-exec-test или //codex-rs/app-server:app-server-all-wine-exec-test. На macOS источник предлагает devbox: сначала applied_devbox ls, затем выбирается имя с codex и выполняется ssh <devbox_name>. Рекомендуется использовать уже существующий checkout в ~/code/codex, чтобы не тратить время и место на несколько копий, но перед тестом нужно сверить SHA и список изменённых файлов между удалённым и локальным checkout. Главные ограничения workflow — требование x86_64 Linux host для текущих remote executor tests, отдельная зависимость Wine/Bazel для Windows-сценария, необходимость opt-in fixture и наличие подходящего окружения. Навык не заменяет assertions конкретного теста, не гарантирует доступность Docker, Wine или devbox и не разрешает считать пропущенный тест эквивалентом успешной проверки.