Engineering / Agent collaboration
OpenCode for Codex
Bounded OpenCode review and collaboration inside Codex.
Archived · 2026-10-05 · No longer maintained. Continued in · turnweft
- 01Define the scope
- 02Delegate the task
- 03Verify the result
01The project
A public Codex plugin that lets OpenCode support code review, troubleshooting, and handoff work from inside Codex. It keeps collaboration controllable with job status, cancellation, and a narrow privacy boundary.
02The 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.
03Key decisions
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.
04My contribution
- Current source version 0.2.4: an explicit absolute cwd grants the target directory for that call only. Workspace grants are checked independently on subsequent calls rather than becoming a session-wide permission.
- 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
More contributions
- 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
05Design in practice
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.
06Outcome and current stage
Public v0.2.4 · eleven typed MCP tools sharing one response envelope · OpenCode review support inside Codex
Technical details & evidence
Role · Sole builder — Codex plugin packaging, MCP tool surface, OpenCode CLI orchestration, transcript boundary, tests
- 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
- TypeScript
- Node.js
- MCP
- Codex Plugin
- OpenCode CLI
- Vitest