1. A shared implementation for opencode-fork targets
opencode is an open-source project with many forks. Forks typically keep opencode's config format byte-for-byte — the same mcp.<name> wrapper with { "type": "local", "command": [...], "enabled": true }, the same https://opencode.ai/config.json $schema, the same XDG-only dir resolution, .jsonc preferred over .json, and the same AGENTS.md instructions convention — but rename the on-disk app identity (config dir under ~/.config/, config file base name, project-local file).
Today the opencode target hard-codes its paths, so supporting any fork means copying ~290 lines where only a handful of strings differ. The installer would benefit from a shared opencode-family implementation, parameterized by a small spec (id, display name, app name on disk, docs URL), that opencode itself and each fork are thin specs over. Fork-specific history should stay per-target — e.g. the pre-#535 %APPDATA% sweep belongs to opencode alone; forks that never shipped through those versions must never touch %APPDATA%.
2. Add CoDev Code, an OpenCode fork
CoDev Code (codev-code on npm, repo, binary codev) is one such fork. CodeGraph currently doesn't work with it at all:
- The opencode target writes
~/.config/opencode/opencode.jsonc / ./opencode.jsonc, but CoDev reads only ~/.config/codev/codev.jsonc / ./codev.jsonc — the MCP entry is invisible to it.
detect() checks for ~/.config/opencode, so on a machine with only CoDev installed, codegraph install --target=auto never even offers the target.
Since the config shape is identical, a codev target built on the shared implementation from point 1 fixes both: auto-detection from ~/.config/codev, and the MCP entry + AGENTS.md block written where the fork actually looks.
PR #1272 implements both points, verified end-to-end (installer output loaded by the real codev binary, codev mcp list → ✓ codegraph connected).
1. A shared implementation for opencode-fork targets
opencode is an open-source project with many forks. Forks typically keep opencode's config format byte-for-byte — the same
mcp.<name>wrapper with{ "type": "local", "command": [...], "enabled": true }, the samehttps://opencode.ai/config.json$schema, the same XDG-only dir resolution,.jsoncpreferred over.json, and the sameAGENTS.mdinstructions convention — but rename the on-disk app identity (config dir under~/.config/, config file base name, project-local file).Today the opencode target hard-codes its paths, so supporting any fork means copying ~290 lines where only a handful of strings differ. The installer would benefit from a shared opencode-family implementation, parameterized by a small spec (id, display name, app name on disk, docs URL), that opencode itself and each fork are thin specs over. Fork-specific history should stay per-target — e.g. the pre-#535
%APPDATA%sweep belongs to opencode alone; forks that never shipped through those versions must never touch%APPDATA%.2. Add CoDev Code, an OpenCode fork
CoDev Code (
codev-codeon npm, repo, binarycodev) is one such fork. CodeGraph currently doesn't work with it at all:~/.config/opencode/opencode.jsonc/./opencode.jsonc, but CoDev reads only~/.config/codev/codev.jsonc/./codev.jsonc— the MCP entry is invisible to it.detect()checks for~/.config/opencode, so on a machine with only CoDev installed,codegraph install --target=autonever even offers the target.Since the config shape is identical, a
codevtarget built on the shared implementation from point 1 fixes both: auto-detection from~/.config/codev, and the MCP entry +AGENTS.mdblock written where the fork actually looks.PR #1272 implements both points, verified end-to-end (installer output loaded by the real
codevbinary,codev mcp list→✓ codegraph connected).