opencode-plugin-codex — OpenCode inside Codex

At a glance

Role Sole builder — Codex plugin packaging, MCP tool surface, OpenCode CLI orchestration, transcript boundary, tests

Problem

Codex and OpenCode are useful in different ways, but switching between them usually loses context and makes reviews harder to track. The goal was to make OpenCode a controlled collaborator inside Codex, with clear job control and a narrow privacy boundary.

Solution

I exposed OpenCode through Codex MCP tools with capability checks, background job status, cancellation, and transcript boundaries. OpenCode can review or troubleshoot, while Codex keeps final control over files, git, and verification.

Impact

Public Codex plugin · tested MCP tools · OpenCode review support inside Codex

My contribution

Codex plugin exposing OpenCode MCP tools: check, run, continue, rescue, review, adversarial review, transfer, status, result, and cancel
Background OpenCode job orchestration, so long-running reviews can be polled, inspected, or cancelled from Codex
Transcript import with a deliberate privacy boundary: by default, opencode_transfer sends visible user/assistant conversation rather than hidden system, developer, or tool output
Review and adversarial-review helpers that make OpenCode useful as a second-pass engineering reviewer before a diff is shipped
Prompt-before-file message handling, a file attachment guard, and explicit blocking guidance for prompts that ask OpenCode to inspect Codex private runtime paths

Technical evidence

Bundled stdio MCP server written in TypeScript, packaged as a Codex plugin
OpenCode CLI discovery, version check, background process management, job ledger, timeout handling, and result retrieval
Narrow context transfer by design: the plugin keeps tool output and hidden instructions out of OpenCode unless a future explicit surface supports it
Safety hardening after public release: task text stays in prompt before file attachments, the file attachment guard rejects prompt text passed as files, and Codex private runtime paths stay outside OpenCode's read scope
Vitest coverage around the MCP tools and the transcript-transfer boundary

Why it exists

The practical use case is collaboration, not novelty: when Codex is deep in a repo, OpenCode can act as a second agent for review, rescue, or adversarial critique. The plugin makes that collaboration explicit and auditable through job status, job result, and cancellation tools.

The important boundary is what does not get transferred. opencode_transfer is intentionally scoped to the visible conversation so private system/developer instructions and tool output are not silently forwarded.

The public hardening work also tightened local delegation mechanics: prompts are kept before files, file attachments are checked as real filesystem attachments, and requests aimed at Codex private runtime paths are treated as out of scope unless an explicit future surface exists.