Module ts_client 

cargo xtask check-ts-client [--write|--check] - keeps crates/shared/codex-app-server-client/clients/typescript/src/generated/openapi-types.ts (a checked-in, openapi-typescript-generated TypeScript client for that crate’s rest feature - see that directory’s own README.md) in sync with the crate’s checked-in openapi.json, and (in --check mode) verifies the package still type-checks.

This is the TypeScript-side analogue of super::scripts_lane_d::check_openapi (which keeps docs/generated/openapi.json in sync with the main soma binary’s own OpenAPI surface) - same --write regenerates / --check verifies shape, different source of truth and a different generator (openapi-typescript’s JS API, not a Rust builder function).

Why this shells out to pnpm, not a Rust HTTP-schema crate

The TypeScript client’s whole point (see bead rmcp-template-g0qf.5) is proving openapi.json is consumable by a real, independent TypeScript toolchain - reimplementing openapi-typescript’s logic in Rust here would defeat that. xtask itself has no Node/pnpm dependency; this module only drives the package’s own package.json scripts (clients/typescript/scripts/generate.mjs and .../check-sync / .../typecheck), the same way a human contributor would.

Why a graceful skip, not a hard failure, when node/pnpm are missing

Mirrors codex_schema::drift’s posture on a missing codex CLI: this repo’s self-hosted CI runners are not guaranteed to have a Node/pnpm toolchain provisioned (see docs/CI.md), and a drift check that hard-fails whenever the runner’s toolchain lags reads as CI flakiness, not a real problem with this PR’s diff. A skip is loud (printed, not swallowed) and still exits 0, so the check is “yes if we can tell, silent-not-lying if we can’t” rather than a false failure.

Constants

TS_CLIENT_DIR 🔒

USAGE 🔒

Functions

current_dir 🔒

missing_toolchain_reason 🔒

None when both node and pnpm are usable; otherwise a human-readable reason naming the first missing tool.

run

run_pnpm 🔒