Skip to content

install refuses OpenCode agent files written by an earlier release, and fails the whole run #2240

Open

Description

@dergachoff

Problem

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.

v0.11.0, macOS arm64.

Activity

  1. added
    bugSomething isn't working
    priority/highNeeds near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.
    ux/behaviorDisplay bugs, docs, adoption UX
    on Sep 19, 2026
  2. DeusData commented on Sep 19, 2026

    @DeusData
    Owner

    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.

    Code checked:

    for (int value = 0; value < (int)CBM_GRAPH_TIER_COUNT; value++) {
    cbm_graph_tier_t tier = (cbm_graph_tier_t)value;
    char path[CLI_BUF_1K];
    if (cbm_tiered_profile_path(profiles.verify_path, tier, path, sizeof(path)) != CLI_OK) {
    record_agent_config_error(false, profiles.label, "agent_path", profiles.verify_path);
    continue;
    }
    if (g_install_plan) {
    plan_record(profiles.label, "agent", path);
    continue;
    }
    if (dry_run) {
    printf(" agent: %s\n", path);
    continue;
    }
    char *current =
    cbm_render_graph_profile(profiles.dialect, tier, access, profiles.binary_path);
    if (!current) {
    record_agent_config_error(false, profiles.label, "agent_render", path);
    continue;
    }
    cbm_graph_access_t alternate_access =
    access == CBM_GRAPH_ACCESS_DIRECT ? CBM_GRAPH_ACCESS_HANDOFF : CBM_GRAPH_ACCESS_DIRECT;
    char *alternate = cbm_render_graph_profile(profiles.dialect, tier, alternate_access,
    profiles.binary_path);
    char *codex_rc1 =
    profiles.dialect == CBM_GRAPH_DIALECT_CODEX && access == CBM_GRAPH_ACCESS_DIRECT
    ? cbm_render_graph_profile_codex_rc1(tier)
    : NULL;
    const char *released[3];
    size_t released_count = 0U;
    if (alternate) {
    released[released_count++] = alternate;
    }
    if (codex_rc1) {
    released[released_count++] = codex_rc1;
    }
    if (tier == CBM_GRAPH_TIER_VERIFY && profiles.legacy_verify_content) {
    released[released_count++] = profiles.legacy_verify_content;
    }
    int result = prepare_config_parent(path)
    ? cbm_text_migrate_owned_document(path, current, released, released_count)
    : CLI_ERR;
    free(codex_rc1);
    free(alternate);
    free(current);
    if (result != CLI_OK) {
    if (result > CLI_OK) {
    printf(" agent: preserved modified profile %s\n", path);
    }
    record_agent_config_error(false, profiles.label, "agent_install", path);
    continue;
    }
    printf(" agent: %s\n", path);
    }

  3. DeusData commented on Sep 26, 2026

    @DeusData
    Owner

    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.

  4. DeusData commented on Oct 19, 2026

    @DeusData
    Owner

    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.

  5. dergachoff commented on Oct 20, 2026

    @dergachoff
    ContributorAuthor

    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.

  6. DeusData commented on Oct 25, 2026

    @DeusData
    Owner

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingeditor/integrationEditor compatibility and CLI integrationpriority/highNeeds near-term maintainer attention; high-impact bug, regression, safety issue, or release blocker.ux/behaviorDisplay bugs, docs, adoption UX

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions