Summary
The opencode adapter ignores the agent's configured path (workingDir). It always runs opencode run with --dir and spawn cwd set to a hardcoded per-agent scratch directory (~/.openagents/agents/<name>), so the opencode subprocess never sees the project the agent was configured for. As a result the model can only reach project files via absolute paths, which lie outside opencode's worktree root, triggering opencode's permission prompt — and in headless opencode run (no TTY) that prompt auto-rejects, surfacing as:
"state":{"status":"error","input":{"filePath":"<project>/...py"},
"error":"The user rejected permission to use this specific tool call."}
It looks intermittent because it only fires when the model actually touches a real project file.
This is not Windows-specific — the hardcoded agentHome ignores workingDir on every platform.
@openagents-org/agent-launcher v0.2.133.
Reproduction
agn create demo --type opencode --path /path/to/some/project
- Connect it to a workspace and @mention it asking it to read or edit a file in that project.
- The
read/edit tool call is rejected with "The user rejected permission to use this specific tool call."
(agn test-llm opencode and plain LLM calls still succeed — this is purely a file-access/working-directory symptom, not a provider/config issue.)
Root cause
src/adapters/opencode.js:
- The constructor documents and receives
opts.workingDir (and the daemon does pass it: src/daemon.js:456 → workingDir: agentCfg.path || undefined), but the value is never used.
this.agentHome is hardcoded to ~/.openagents/agents/<agentName> (line ~35).
_runOpencode builds const cmd = [binary, 'run', '--format', 'json', '--dir', this.agentHome] (line ~312) and spawns with cwd: this.agentHome (line ~340).
So the opencode subprocess starts in an empty scratch directory regardless of the configured path.
Suggested fix
Use the configured working directory for opencode's --dir/cwd, keeping agentHome for sessions/skills storage:
// constructor
this.workingDir = opts.workingDir || this.agentHome;
// _runOpencode
const cmd = [binary, 'run', '--format', 'json', '--dir', this.workingDir];
// ...
spawn(spawnBinary, spawnArgs, { /* ... */ cwd: this.workingDir, /* ... */ });
Note: stored opencode session IDs (~/.openagents/agents/<name>/sessions.json) are created against a project dir, so changing --dir invalidates old ones — --session <oldId> with a new --dir 404s. Resetting that file (or scoping sessions by working dir) avoids a confusing follow-up error.
Related
Same launcher version surfaced a separate Windows PATH bug in paths.js — see #434. This one is independent (opencode adapter only).
Summary
The opencode adapter ignores the agent's configured
path(workingDir). It always runsopencode runwith--dirand spawncwdset to a hardcoded per-agent scratch directory (~/.openagents/agents/<name>), so the opencode subprocess never sees the project the agent was configured for. As a result the model can only reach project files via absolute paths, which lie outside opencode's worktree root, triggering opencode's permission prompt — and in headlessopencode run(no TTY) that prompt auto-rejects, surfacing as:It looks intermittent because it only fires when the model actually touches a real project file.
This is not Windows-specific — the hardcoded
agentHomeignoresworkingDiron every platform.@openagents-org/agent-launcherv0.2.133.Reproduction
agn create demo --type opencode --path /path/to/some/projectread/edittool call is rejected with"The user rejected permission to use this specific tool call."(
agn test-llm opencodeand plain LLM calls still succeed — this is purely a file-access/working-directory symptom, not a provider/config issue.)Root cause
src/adapters/opencode.js:opts.workingDir(and the daemon does pass it:src/daemon.js:456→workingDir: agentCfg.path || undefined), but the value is never used.this.agentHomeis hardcoded to~/.openagents/agents/<agentName>(line ~35)._runOpencodebuildsconst cmd = [binary, 'run', '--format', 'json', '--dir', this.agentHome](line ~312) and spawns withcwd: this.agentHome(line ~340).So the opencode subprocess starts in an empty scratch directory regardless of the configured
path.Suggested fix
Use the configured working directory for opencode's
--dir/cwd, keepingagentHomefor sessions/skills storage:Note: stored opencode session IDs (
~/.openagents/agents/<name>/sessions.json) are created against a project dir, so changing--dirinvalidates old ones —--session <oldId>with a new--dir404s. Resetting that file (or scoping sessions by working dir) avoids a confusing follow-up error.Related
Same launcher version surfaced a separate Windows PATH bug in
paths.js— see #434. This one is independent (opencode adapter only).