Subagent asking for permission even though it has already

[MartyMcFlyInTheSky]

Description

My gitlab subagent has these permissions:

---
description: Use for GitLab tasks via the glab CLI, including issues, merge requests, pipelines, releases, and GitLab API queries.
mode: subagent
permission:
  edit: deny
  bash:
    "*": ask
    "glab *": allow
    "cat *": allow
    "git status *": allow
    "git diff *": allow
    "git log *": allow
    "git branch *": allow
    "git fetch *": allow
---

And it still always asks when accessing glab. So when I accept, it says it "added rule to allow glab * for this session" - which I already have? So why does it ask? Seems like a bug.

OpenCode version

1.14.35

[stephanschielke]

I'm hitting what appears to be the same root cause but with a more severe symptom.

Setup: Using oh-my-openagent plugin which creates agents (Sisyphus, Hephaestus) with their own permission blocks. Global config has "bash": { "*": "allow" }. The resolved agent permission (via opencode debug agent) correctly shows { "permission": "bash", "pattern": "*", "action": "allow" }.

Symptom: Any bash command containing the literal word git - including echo "git" - throws a JavaScript TypeError:

Attempted to assign to readonly property.

The error occurs before the command executes. It's not a permission denial — it's a crash in the permission checking code path.

Reproduction:

# Works:
echo hello
echo "xgit"

# Crashes with "Attempted to assign to readonly property":
echo "git"
echo "a git b"
git status
printf "git\n"

Analysis: The tree-sitter parser in bash.ts extracts the word git from the command text as a pattern candidate. It then attempts to run the permission check / "always" list flow, which tries to update part.state on a MessageV2.ToolPart object that has already been sealed/frozen by the Effect runtime. The error is a JS TypeError, not a permission denial.

The key evidence that this is a parser/state bug (not a config issue):

• echo "git" fails - the word git appears inside a string literal, not as a command

but if you use "bypass" strategies (which I will not post here because otherwise agents might pick up on it and will start to bypass their set permissions) then it works.

Environment:

• OpenCode 1.14.35
• oh-my-openagent@latest plugin
• Global permission: "bash": { "*": "allow" }
• Agent-level resolved permission also shows bash allow
• Linux, zsh

Additional context: This started immediately after upgrading from 1.14.33 → 1.14.35. No config changes were made. The issue persists across session forks and restarts (same binary in memory). It does NOT affect sessions started fresh on 1.14.37 (untested yet — will update).

---

Meanwhile 1.14.37 has been released.
Looks like there have been major changes.

[ouchxp]

Same here, seeing a lot of errors Attempted to assign to readonly property. after the version update

[stephanschielke]

I tracked this down further. The root cause is Bun's minifier (minify: true in script/build.ts) miscompiling the Stream.runFold accumulator-mutation callback in Git.run()'s collect() helper (introduced in #25581).

Evidence:

Build config	Result
bun run from source	✅ Works
Bun.build({ compile: true, minify: false })	✅ Works
Bun.build({ compile: true, minify: true })	❌ Attempted to assign to readonly property

Known class of Bun minifier bugs: oven-sh/bun#13394, oven-sh/bun#11754, oven-sh/bun#12655.

Fix PR: #25867 (issue: #25873) — replaces the accumulator mutation with Stream.runForEach + local variables.

@MartyMcFlyInTheSky @ouchxp — could you test if this fixes your issue? You can build from my fork:

git clone https://github.com/stephanschielke/opencode.git
cd opencode
git checkout fix/git-runfold-readonly-mutation
bun install
cd packages/opencode
bun run build --single
# binary at dist/opencode-<platform>/bin/opencode

[stephanschielke]

Quick correction / update from my earlier comments here:

I previously (a) speculated about a permission/tree-sitter path and (b) later claimed the root cause was the Git.run() collect() Stream.runFold reducer being miscompiled by Bun’s minifier.

After more investigation, that root-cause claim is not confirmed:

• I could not capture a stack trace that points at the collect() reducer.
• A compiled-binary stress test that calls Git.run() directly did not reproduce the readonly-property error.
• The /session/:id/shell endpoint (direct shell execution) did not reproduce this error for us, even when exercised repeatedly.

The failure still appears tied to the compiled+minified binary and the full chat/tool-call runtime path (the one that goes through ai.streamText({ tools })). Best current explanation is still “Bun minifier/codegen bug that only manifests with the full module graph + streamText tool-calling pipeline”, but the exact throw site is still unknown.

I’ve updated #25873 (and PR #25867) to reflect only what’s verified and to explicitly mark the root cause as still under investigation.

If anyone can capture a stack trace from a failing compiled+minified build with sourcemaps enabled, that would likely pinpoint the real assignment that throws.