fix(codex): make marketplace MCP bootstrap self-contained

[TyceHerrman]

What / Why / How

Make the Codex marketplace MCP bootstrap self-contained enough to start from the installed plugin directory without a separate global context-mode install or a first-run node_modules dependency install.

This keeps Codex on a Codex-specific launcher at .codex-plugin/plugin-start.mjs. The launcher validates the packaged artifact, wires bundled pure-JS runtime dependencies for turndown and turndown-plugin-gfm, preserves Codex MCP env/approval metadata, then imports server.bundle.mjs. It also adds a Codex doctor probe that starts the plugin MCP command from .codex-plugin/mcp.json and verifies tools/list exposes ctx_*.

Affected platforms

• Claude Code
• Cursor
• VS Code Copilot (GitHub Copilot)
• JetBrains Copilot
• Gemini CLI
• Qwen Code
• OpenCode
• KiloCode
• Codex CLI
• OpenClaw (Pi Agent)
• Pi
• Kiro
• Antigravity
• Zed
• All platforms

Test plan

Added/updated tests for:

• Codex manifest launch path and metadata.
• Packaged-plugin MCP startup without node_modules.
• Missing-artifact fast failure.
• Codex vendor resolver idempotence and isolation from shared lifecycle state.
• Codex doctor MCP probe behavior.
• npm package inclusion for .codex-plugin/plugin-start.mjs, vendored runtime files, and server.bundle.mjs.

Verification run on latest base:

• git diff --check
• npm pack --dry-run --json --cache /private/tmp/context-mode-npm-cache plus explicit package file check

Local caveat:

• npm run build and focused Vitest were attempted after the latest rebase, but the local repo's esbuild binary hangs even on --version, and Vitest also hung without output. cli.bundle.mjs was regenerated with a working esbuild 0.27.7 binary from an installed context-mode package. Earlier focused Codex/plugin tests passed before the latest upstream refresh.

Checklist

• Tests added/updated (TDD: red -> green)
• npm test passes
• npm run typecheck passes
• Docs updated if needed (README, platform-support.md)
• No Windows path regressions (forward slashes only)
• Targets next branch (unless hotfix)

Cross-platform notes

The Codex launcher uses Node path helpers (resolve, join, fileURLToPath) for filesystem paths. The manifest keeps Codex's existing cwd, env.CONTEXT_MODE_PLATFORM, and default_tools_approval_mode fields while changing only the launcher args to the Codex-specific bootstrap.

[mksglu]

@TyceHerrman CI

[mksglu]

No, no. What's that 🙂

[TyceHerrman]

it was a temporary esbuild entrypoint so the Codex marketplace artifact could generate physical .codex-plugin/vendor/* bundles for turndown and turndown-plugin-gfm without shipping node_modules. updated with scripts/build-codex-vendor.mjs, which explicitly resolves the packages and builds the Codex-only vendor bundles.

[mksglu]

Hi @TyceHerrman! Thanks a lot for the PR. So what's these files actually? Please could you provide me more information about that and other file

[TyceHerrman]

.codex-plugin/vendor/turndown.cjs and .codex-plugin/vendor/turndown-plugin-gfm.cjs are generated CommonJS bundles for the pure JS HTML-to-Markdown deps used by ctx_fetch_and_index. Codex marketplace installs can start without node_modules, but server.bundle.mjs still resolves physical module paths and injects them into a sandbox subprocess, so the codex artifact needs physical files for those deps.

scripts/build-codex-vendor.mjs is the source/build recipe. it resolves the real npm package entrypoints with createRequire(...).resolve(...) and uses esbuild to emit the vendor files. turndown.cjs and turndown-plugin-gfm.cjs are generated artifacts, and ctx already tracks other generated runtime bundles because plugin installs need to run from the checked-out/package artifact without a build step.