Permission model: project-local routine approvals + sibling worktree trust are too noisy for autonomous contributor sessions #23258

Summary

OpenCode still becomes too approval-noisy for long-running autonomous contributor sessions, even when the project has already approved routine repo work conceptually.

The main pain point is not dangerous commands. It is repeated prompts for normal project work like:

• git fetch / branch / merge / commit / push
• gh issue/pr status/comment/update commands
• file reads/writes inside sibling worktrees for the same repo family
• subagent/task launches used for review + queue triage pressure

Why this matters

In a multi-worktree contributor workflow, an autonomous agent may keep:

• one write lane on repo-A
• another write lane on repo-A-389
• a third read-only research lane on repo-A-515

Even when the operator wants these to run without hand holding, the effective permission experience is still too noisy unless every project config is tuned very aggressively.

Two specific problems:

1. always approvals are still session-scoped and do not solve the “same routine action tomorrow / next restart / next connected client” problem well enough.
2. external_directory defaults to ask, so sibling worktrees of the same trusted repo family can still trigger approval churn unless the project explicitly whitelists the broader parent path.

Current documented behavior

The docs currently say:

• most permissions default to allow
• external_directory defaults to ask
• always approvals are for the rest of the current session
• project config can override with permission

Relevant docs:

• https://opencode.ai/docs/permissions
• https://opencode.ai/docs/config

Why this still feels broken in practice

For autonomous coding-agent workflows, the operator expectation is often:

“I already trust routine git/file/project work in this repo. Stop interrupting me.”

But the real behavior is still fragile across:

• restarts
• multiple worktrees
• project-local * = ask policies that need many explicit exceptions
• repo families that share a trusted parent directory but not the exact original cwd

Requested improvements

At least one of these would materially help:

1. Persistent project-scoped approval mode

   • a first-class mode that persists routine approvals across sessions for one trusted project

2. Repo-family / sibling-worktree trust

   • an easier way to trust all worktrees under the same parent repo path without manually relying on external_directory path globs

3. A built-in “autonomous contributor” permission preset

   • allow routine git/gh/read/edit/task/webfetch in-project
   • still deny obviously dangerous categories like rm -rf, kubectl, package installs, etc.

4. Better UX around what is actually causing the prompt

   • especially when the real blocker is external_directory rather than the tool itself

Related existing issues

This is adjacent to, but not exactly the same as:

• [FEATURE]: Make Allow always permission option persist across sessions #20066 — persist “Allow always” across sessions
• [FEATURE]: Restore per-session auto-accept permissions toggle in Desktop UI #21578 — restore per-session auto-accept toggle
• Granular permissions not working (or documentation bad?) #20307 — granular permissions confusion

This issue is specifically about the operational gap for autonomous multi-worktree contributor sessions.

Concrete local workaround we are using

The best current project-local fix appears to be:

• set broad routine permissions in opencode.json
• explicitly allow external_directory for the trusted parent worktree path
• keep only truly dangerous commands denied

That works, but it is too manual and too easy to get wrong.