fix: add default agent permissions to prevent root-level denies from silencing agents

[mmustafasenoglu]

Fixes #52

Problem

Micode agents define no permission field in their AgentConfig. When a project's opencode.json sets root-level permission denies (e.g. "edit": "deny" or "bash": "deny"), all micode agents inherit those denies and become non-functional — they spawn but return empty results because they can't use any tools.

Fix

Add a centralized AGENT_PERMISSIONS object in src/agents/index.ts with sensible defaults for each agent role:

Role	Permissions	Agents
readOnly	edit: deny	codebase-locator, codebase-analyzer, pattern-finder, artifact-searcher, probe, all mm-* read-only agents
research	edit: deny, webfetch: allow	planner, bootstrapper
write	edit: allow	ledger-creator, mm-constraint-writer
build	edit: allow, bash: allow	implementer, reviewer
orchestration	edit: allow, bash: allow, webfetch: allow	commander, brainstormer, executor, octto, project-initializer

Each agent now explicitly declares the permissions it needs, preventing root-level denies from breaking functionality.

Why this approach

The AgentConfig permission type only supports: edit, bash, webfetch, doom_loop, external_directory. Other tool access (read, glob, grep, task) is controlled at a different level via the tools config in individual agent files — those are already correctly configured.

The fix targets the specific permission keys that the type supports and that are most commonly denied at root level.

Testing

• bun run typecheck passes
• bun run build passes
• No behavior change for projects without root-level permission denies

---

Summary by cubic

Prevents root-level permission denies from silencing agents by adding role-based default permissions and deep‑merging per‑agent permission with user config. Previously agents inherited root denies and returned empty results; now each agent declares the minimal permissions it needs while user per‑agent overrides still take precedence.

• Adds centralized AGENT_PERMISSIONS with five roles using only edit, bash, webfetch; readOnly/research explicitly set edit: deny to prevent unintended edits by probe, planner, and bootstrapper.
• Assigns a role-specific permission to every agent in src/agents/index.ts.
• Deep‑merges permission in mergePluginAgentConfig so user per‑agent keys override plugin defaults.
• Behavior: projects with root-level denies now work; others unchanged. No migration required.

^{Written for commit 042bd6a. Summary will update on new commits.}

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/agents/index.ts">

<violation number="1" location="src/agents/index.ts:73">
P1: When a user configures an explicit permission for a plugin agent, these new fields replace that agent's permission object during `mergePluginAgentConfig`, removing deliberate per-agent denies. Merge permission keys with existing agent values taking precedence, using `AGENT_PERMISSIONS` only for unspecified defaults.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: When a user configures an explicit permission for a plugin agent, these new fields replace that agent's permission object during mergePluginAgentConfig, removing deliberate per-agent denies. Merge permission keys with existing agent values taking precedence, using AGENT_PERMISSIONS only for unspecified defaults.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/agents/index.ts, line 73:

<comment>When a user configures an explicit permission for a plugin agent, these new fields replace that agent's permission object during `mergePluginAgentConfig`, removing deliberate per-agent denies. Merge permission keys with existing agent values taking precedence, using `AGENT_PERMISSIONS` only for unspecified defaults.</comment>

<file context>
@@ -30,35 +30,175 @@ import { probeAgent } from "./probe";
+  [PRIMARY_AGENT_NAME]: {
+    ...primaryAgent,
+    model: DEFAULT_MODEL,
+    permission: AGENT_PERMISSIONS.orchestration,
+  },
+  brainstormer: {
</file context>

[mmustafasenoglu]

Addressed both cubic review findings:

1. P3 (readOnly deny): Removed edit: "deny" from readOnly/research roles. The agents' own tools config already disables edit, so omitting it here lets the global permission config apply — no behavior change for existing projects.

2. P1 (permission merge): Updated mergePluginAgentConfig to deep-merge the permission field. User-configured per-agent permission keys now take precedence over plugin defaults instead of being overwritten.

Typecheck ✅ Build ✅ 488 tests pass ✅

[cubic-dev-ai]

All reported issues were addressed across 2 files (changes from recent commits).

<sub>Reply with feedback, questions, or to request a fix.

Re-trigger cubic</sub>

[mmustafasenoglu]

Good catch — you're right. probe, planner, and bootstrapper don't disable edit in their tools config, so removing edit: "deny" would let them edit files via the global edit: "allow".

Restored edit: "deny" on both readOnly and research roles, and updated the comment to explain why it's necessary even though some agents (codebase-locator, pattern-finder, etc.) already disable edit in their tools config — the deny covers the agents that don't.

Typecheck ✅ Build ✅ 488 tests pass ✅

[cubic-dev-ai]

2 issues found across 1 file (changes from recent commits).

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="src/agents/index.ts">

<violation number="1" location="src/agents/index.ts:39">
P3: The new readOnly comment lists `reviewer` as one of the read-only agents that disables edit via its tools config, but in this same file `reviewer` is assigned `AGENT_PERMISSIONS.build` (`edit: "allow"`, `bash: "allow"`), not `readOnly`. The comment therefore overstates which agents the readOnly `edit: "deny"` covers and misleads a maintainer into thinking reviewer is read-only. Remove `reviewer` from the list (or clarify that it is covered by the build role instead).</violation>

<violation number="2" location="src/agents/index.ts:42">
P1: The shared research permission denies `edit`, but `plannerAgent` must use `Write` to create the implementation plan. This causes planner runs to fail or return without a plan; give planner a separate write-capable permission profile while keeping bootstrapper read-only.</violation>
</file>

<sub>Tip: Review your code locally with the cubic CLI to iterate faster.

Re-trigger cubic</sub>

[cubic-dev-ai]

P1: The shared research permission denies edit, but plannerAgent must use Write to create the implementation plan. This causes planner runs to fail or return without a plan; give planner a separate write-capable permission profile while keeping bootstrapper read-only.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/agents/index.ts, line 42:

<comment>The shared research permission denies `edit`, but `plannerAgent` must use `Write` to create the implementation plan. This causes planner runs to fail or return without a plan; give planner a separate write-capable permission profile while keeping bootstrapper read-only.</comment>

<file context>
@@ -32,18 +32,21 @@ import { reviewerAgent } from "./reviewer";
+  // codebase-analyzer, pattern-finder, reviewer, artifact-searcher, mm-*)
+  // but others like probe don't — so we set edit: "deny" here to cover all.
+  readOnly: {
+    edit: "deny",
+  } as const,
 
</file context>

[cubic-dev-ai]

P3: The new readOnly comment lists reviewer as one of the read-only agents that disables edit via its tools config, but in this same file reviewer is assigned AGENT_PERMISSIONS.build (edit: "allow", bash: "allow"), not readOnly. The comment therefore overstates which agents the readOnly edit: "deny" covers and misleads a maintainer into thinking reviewer is read-only. Remove reviewer from the list (or clarify that it is covered by the build role instead).

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At src/agents/index.ts, line 39:

<comment>The new readOnly comment lists `reviewer` as one of the read-only agents that disables edit via its tools config, but in this same file `reviewer` is assigned `AGENT_PERMISSIONS.build` (`edit: "allow"`, `bash: "allow"`), not `readOnly`. The comment therefore overstates which agents the readOnly `edit: "deny"` covers and misleads a maintainer into thinking reviewer is read-only. Remove `reviewer` from the list (or clarify that it is covered by the build role instead).</comment>

<file context>
@@ -32,18 +32,21 @@ import { reviewerAgent } from "./reviewer";
-  // permission config (edit: "allow", bash: "allow") apply.
-  readOnly: {} as const,
+  // Read-only agents: some disable edit via tools config (codebase-locator,
+  // codebase-analyzer, pattern-finder, reviewer, artifact-searcher, mm-*)
+  // but others like probe don't — so we set edit: "deny" here to cover all.
+  readOnly: {
</file context>