Problem Statement
I've been switching back and forth between codex and opencode with spec-kit for a while now using
specify integration install opencode --force
specify integration use opencode
with no observed issues.
With Spec Kit 1.0.4:
specify integration install opencode
is correctly rejected when Codex is already installed. Installing with:
specify integration install opencode --force
creates a project where specify integration status --json reports:
{
"status": "error",
"installed_integrations": ["codex", "opencode"],
"multi_install_safe": false,
"findings": [
{
"code": "unsafe-multi-install",
"message": "Installed integrations are not all declared multi-install safe: opencode"
}
]
}
Reproduction And Observed Invariants
In a newly initialized, isolated fixture, we verified:
- Codex uses
.agents/skills/... and OpenCode uses .opencode/commands/....
Their agent roots and command directories are distinct.
- Forced OpenCode installation created the expected OpenCode command files
without removing Codex skill files.
- Spec Kit created separate manifests:
.specify/integrations/codex.manifest.json and
.specify/integrations/opencode.manifest.json.
specify integration use opencode and specify integration use codex both
completed while retaining both integration roots.
- Repeating
integration use for either selected default did not change the
fixture file manifest.
integration status --json reported no missing or modified managed files
for either integration. The only reported error was OpenCode's missing
multi-install-safe declaration.
This aligns with the published multi-install-safe criteria: static, distinct
agent roots and command directories; separate install manifests; stable command
invocation configuration; and no overlapping managed integration files.
Proposed Solution
Mark opencode as multi-install safe
Alternatives Considered
- Don't mark it as multi-install safe.
- Work with opencode upstream to make it multi-install safe
Component
Agent integrations (command files, workflows)
AI Agent (if applicable)
opencode
Use Cases
Working in projects where some devs prefer one agent vs another. Even a single dev who prefers say the codex experience however sometimes needs to use no-openai models well so switches temporarily to opencode
Acceptance Criteria
No response
Additional Context
No response
AI Disclosure
Some of the compatibility testing was done by gpt-5.6-terra at high in human-supervised mode.
Problem Statement
I've been switching back and forth between codex and opencode with spec-kit for a while now using
with no observed issues.
With Spec Kit
1.0.4:is correctly rejected when Codex is already installed. Installing with:
creates a project where
specify integration status --jsonreports:{ "status": "error", "installed_integrations": ["codex", "opencode"], "multi_install_safe": false, "findings": [ { "code": "unsafe-multi-install", "message": "Installed integrations are not all declared multi-install safe: opencode" } ] }Reproduction And Observed Invariants
In a newly initialized, isolated fixture, we verified:
.agents/skills/...and OpenCode uses.opencode/commands/....Their agent roots and command directories are distinct.
without removing Codex skill files.
.specify/integrations/codex.manifest.jsonand.specify/integrations/opencode.manifest.json.specify integration use opencodeandspecify integration use codexbothcompleted while retaining both integration roots.
integration usefor either selected default did not change thefixture file manifest.
integration status --jsonreported no missing or modified managed filesfor either integration. The only reported error was OpenCode's missing
multi-install-safe declaration.
This aligns with the published multi-install-safe criteria: static, distinct
agent roots and command directories; separate install manifests; stable command
invocation configuration; and no overlapping managed integration files.
Proposed Solution
Mark opencode as multi-install safe
Alternatives Considered
Component
Agent integrations (command files, workflows)
AI Agent (if applicable)
opencode
Use Cases
Working in projects where some devs prefer one agent vs another. Even a single dev who prefers say the
codexexperience however sometimes needs to use no-openai models well so switches temporarily toopencodeAcceptance Criteria
No response
Additional Context
No response
AI Disclosure
Some of the compatibility testing was done by
gpt-5.6-terraathighin human-supervised mode.