You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
install refuses OpenCode agent files written by an earlier release, and fails the whole run #2240
Upgrading a 0.9.1-rc.1-era setup to v0.11.0, install -y refuses three OpenCode agent files that cbm's own installer wrote, and the refusal fails the entire install.
Evidence
error: agent_config agent=OpenCode op=agent_install path=~/.config/opencode/agents/codebase-memory-scout.md (target: regular file, 1729 bytes)
error: one or more agent configurations failed; the published/current executable was kept, and PATH/index cleanup was not attempted
All three files are dated 2026-07-31 21:13 — written by the rc.1 installer, never touched by me. Moving them aside and rerunning install -y --clients=opencode succeeds with zero errors, and the files it then writes differ from the rc.1 ones by exactly two lines:
+ tool_search: allow
+ tool_search_regex: allow
So the renderer changed, the previous rendering isn't registered anywhere, and cbm's own output now reads as a foreign file.
Expected fix
Register the pre-0.11.0 OpenCode agent rendering as a known released shape so upgrades migrate it, the way #1408 did for the rc.1 Codex profiles. The escalation is worth a second look too — #1656 fixed exactly that for Hermes, and here one refused file skips PATH and index cleanup for the whole run.
Thank you for isolating this to the two added permission lines and for preserving the old files. I checked current main (59a05eb): the OpenCode renderer includes tool_search and tool_search_regex, while the profile migration path recognizes the current/alternate renderings, a Codex-specific rc.1 shape, and an optional legacy verify profile. It does not provide the equivalent prior OpenCode rendering for all three tiers.
This is a high-priority upgrade compatibility bug. The fix needs to recognize the exact released OpenCode shapes while continuing to preserve genuinely user-modified profiles. The whole-install failure behavior also needs a separate look; we should not silently overwrite an unrecognized file to make the error disappear. Your report provides enough detail to investigate, so this is not waiting on more reporter information.
Thank you for narrowing this down to the two added permission lines and for keeping the original files. That's exactly what the fix needed!
A fix is prepared. It adds the earlier OpenCode rendering, from before tool_search/tool_search_regex were added, to the shapes the installer recognises as its own. An upgrade then rewrites those three profiles in place, and uninstall removes them as owned. A profile you actually edited is still preserved. It will be linked here when the PR opens; until it's released, moving the files aside remains the workaround.
The second point, one refused file stopping PATH and index cleanup for the whole run, is not part of that fix. We'll keep it open here. Thanks for pointing to #1408 and #1656; they were the right precedents.
Thank you again for preserving and comparing the older OpenCode profiles. I have no verified update on the prepared migration fix or the separate whole-install failure behavior. Recognizing released shapes while preserving user edits remains the boundary to check.
The OpenCode half is fixed on v0.12.1. I recreated the old shape (the three profiles without the tool_search / tool_search_regex lines) and ran install -y --clients=opencode. It exited 0 and rewrote all three in place, byte-identical to the current render, which matches #2393. The only part left open here is the whole run failing on one refused file.
Thank you for verifying the old OpenCode profiles on v0.12.1 and confirming they now migrate correctly. That leaves the whole-run failure on one refused file as the remaining issue here. Sorry for the delay on that part; I’ll follow up soon.
Activity
DeusData commentedon Sep 19, 2026
Thank you for isolating this to the two added permission lines and for preserving the old files. I checked current main (59a05eb): the OpenCode renderer includes
tool_searchandtool_search_regex, while the profile migration path recognizes the current/alternate renderings, a Codex-specific rc.1 shape, and an optional legacy verify profile. It does not provide the equivalent prior OpenCode rendering for all three tiers.This is a high-priority upgrade compatibility bug. The fix needs to recognize the exact released OpenCode shapes while continuing to preserve genuinely user-modified profiles. The whole-install failure behavior also needs a separate look; we should not silently overwrite an unrecognized file to make the error disappear. Your report provides enough detail to investigate, so this is not waiting on more reporter information.
Code checked:
codebase-memory-mcp/src/cli/cli.c
Lines 8670 to 8724 in 59a05eb
DeusData commentedon Sep 26, 2026
Thank you for narrowing this down to the two added permission lines and for keeping the original files. That's exactly what the fix needed!
A fix is prepared. It adds the earlier OpenCode rendering, from before
tool_search/tool_search_regexwere added, to the shapes the installer recognises as its own. An upgrade then rewrites those three profiles in place, and uninstall removes them as owned. A profile you actually edited is still preserved. It will be linked here when the PR opens; until it's released, moving the files aside remains the workaround.The second point, one refused file stopping PATH and index cleanup for the whole run, is not part of that fix. We'll keep it open here. Thanks for pointing to #1408 and #1656; they were the right precedents.
DeusData commentedon Oct 19, 2026
Thank you again for preserving and comparing the older OpenCode profiles. I have no verified update on the prepared migration fix or the separate whole-install failure behavior. Recognizing released shapes while preserving user edits remains the boundary to check.
dergachoff commentedon Oct 20, 2026
The OpenCode half is fixed on v0.12.1. I recreated the old shape (the three profiles without the
tool_search/tool_search_regexlines) and raninstall -y --clients=opencode. It exited 0 and rewrote all three in place, byte-identical to the current render, which matches #2393. The only part left open here is the whole run failing on one refused file.DeusData commentedon Oct 25, 2026
Thank you for verifying the old OpenCode profiles on v0.12.1 and confirming they now migrate correctly. That leaves the whole-run failure on one refused file as the remaining issue here. Sorry for the delay on that part; I’ll follow up soon.