Repository navigation
opencode run --auto hangs indefinitely when a Task subagent requests permission #36868
Description
Description
In OpenCode 1.17.20, a non-interactive opencode run --auto session hangs indefinitely when a Task subagent emits a permission request.
The root session's permission requests are handled by --auto, but permission events from child sessions are ignored. The parent is awaiting the Task result, the child is awaiting a permission reply, and neither can make progress.
This was reproduced three times in the same benchmark. In each run the parent reached the Task subagent, the child requested external_directory, and the process remained alive with no further log output.
Command
opencode run --format json --auto --model <provider>/<model> "Complete the task and delegate the required review to the configured subagent."Minimal setup
Create a read-only subagent that can use read, glob, and grep, then have the primary agent delegate a review which causes the subagent to inspect a path outside the current working directory.
Example subagent:
---
description: Read-only reviewer
mode: subagent
tools:
read: true
grep: true
glob: true
write: false
edit: false
bash: false
---
Inspect the requested files and return a concise review.Relevant project permissions:
{
"permission": {
"read": "allow",
"edit": "allow",
"bash": "allow",
"task": "allow",
"skill": "allow"
}
}Actual behavior
The logs show that the child session is created and starts normally:
evaluated permission=task pattern=<reviewer> action.action=allow
created id=<child-session> parentID=<root-session> agent=<reviewer>
stream session.id=<child-session> mode=subagent
The child later asks for external-directory permission:
asking id=<permission-id> permission=external_directory patterns=["C:\\...\\outside\\*"]
After this line:
- no permission response is logged;
- no further model requests are made;
- CPU and network activity become idle;
- the OpenCode process remains alive indefinitely;
- the parent never receives the Task result.
The Java/source files had not been modified when the hang occurred.
Expected behavior
With --auto, permission requests belonging to Task child sessions should be handled consistently with requests from the root session.
Without --auto, a non-interactive run should reject the request or exit with an actionable error. It should never wait forever for input that cannot be supplied.
Likely cause
The current non-interactive event loop only handles permission events whose session ID equals the root session ID:
if (event.type === "permission.asked") {
const permission = event.properties
if (permission.sessionID !== sessionID) continue
if (auto) {
await client.permission.reply({
requestID: permission.id,
reply: "once",
})
} else {
// auto-reject
}
}A permission request from a Task child session has a different sessionID, so it hits continue and is never approved or rejected. Meanwhile, the parent Task call is waiting for the child session to finish.
Source: https://github.com/anomalyco/opencode/blob/dev/packages/opencode/src/cli/cmd/run.ts#L3623-L3658
A safe fix may need to handle permission events for descendants of the active root session while avoiding replies to unrelated sessions. A timeout/error path would also prevent permanent deadlock.
Reproducibility
Observed in three independent clean workspaces:
| Attempt | Result |
|---|---|
| 1 | Child external_directory permission requested; process hung until external timeout |
| 2 | Same behavior in a fresh workspace |
| 3 | Same behavior; process remained alive for more than 60 minutes with no new log output |
No provider API error or rate-limit error was present.
Environment
- OpenCode: 1.17.20
- OS: Windows
- Shell: PowerShell
- Invocation: non-interactive
opencode run --format json --auto - Plugins: none
- MCP: one local stdio server
- Model/provider: GLM-5.2 through a custom provider (the hang occurs after the permission request, not during an LLM request)
Related
- [FEATURE]: Add non-interactive mode to "opencode run" #10411 — non-interactive
opencode runshould not wait for permission input - Subagents don’t respect
"*": "allow"agent permissions #12566 — subagents do not respect parent permissions - Truncated tool calls are misclassified and unrecoverable (finishReason: length + repairToolCall + doom loop) #18108 — ask-type permissions in subagents can block the parent indefinitely
- Improve transitive permissions for agents subagents and tasks #20549 / fix(opencode): preserve
external_diranddenyparent permissions in task child sessions #23290 — transitive permission handling and the partial child-session permission fix
Activity
github-actions commentedon Jul 14, 2026
This issue might be a duplicate of existing issues. Please check:
opencode run: any permission resolving to "ask" hangs forever, no timeout (three repro paths) #36762: Headlessopencode run: any permission resolving to "ask" hangs forever, no timeout — very similar scenario: non-interactive run with unresolvable permission requests causing indefinite hangimenyoo2 commentedon Jul 23, 2026
any workaround for this ?
imenyoo2 commentedon Jul 24, 2026
adding "permissions": "allow" to opencode.json worked for me
eummo commentedon Jul 29, 2026
The blanket
allowworkaround avoids the hang because it prevents the child session from creating an unresolved permission request, but it also removes that permission boundary for every matching tool. I would not recommend it for untrusted repositories or unattended runs.A safer temporary workaround is to make only the permissions required by the delegated task resolve explicitly to
allowordeny(rather thanask), or disable the permission-requiring tool for that subagent. This avoids leaving a headless child request pending without granting unrelated capabilities.The underlying issue is that headless
opencode runhandles permission requests from the root session but can miss requests created by descendant Task sessions. #36898 adds descendant-session tracking and a regression test: descendant requests follow the existing--autobehavior (approve with--auto, reject without it) instead of waiting indefinitely.If anyone still reproduces this on a recent build, the most useful details would be the OpenCode version, whether
--autowas used, the permission type requested by the child, and a minimal permission configuration.rekram1-node commentedon Aug 22, 2026
fixed on latest