opencode-plugin-codex — OpenCode inside Codex

Project overview

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

Scenario

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.

Product strategy

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.

Outcome and current stage

Public v0.2.3 · eleven typed MCP tools sharing one response envelope · OpenCode review support inside Codex

My contribution

Codex plugin exposing eleven OpenCode MCP tools: check, run, continue, rescue, review, adversarial review, transfer, sessions, status, result, and cancel
Background OpenCode job orchestration, so long-running reviews can be polled, inspected, or cancelled from Codex
Transcript import with a defined privacy boundary: opencode_transfer carries the visible user/assistant conversation, while hidden system, developer, and tool output stay within Codex
Review and adversarial-review entry points that put OpenCode in a second-pass reviewer role before a diff is shipped, with Codex still deciding what the findings are worth
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 visible conversation is the transfer surface, while tool output and hidden instructions remain within Codex
Safety hardening after public release: task text stays in prompt before file attachments, the file attachment guard rejects prompt text passed as files, and prompts that reach for Codex private runtime paths are refused unless that access is explicitly authorized, keeping them 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: when Codex is deep in a repo, OpenCode can act as a second agent for review, rescue, or adversarial critique. Job status, result, and cancellation tools keep that collaboration visible and controllable.

opencode_transfer carries the visible conversation into OpenCode, while private system/developer instructions and tool output stay within Codex.

The public hardening work also tightened local delegation mechanics: prompts stay before files, attachments are verified as filesystem files, and a prompt reaching for Codex private runtime paths is refused unless that access has been explicitly authorized.