Repository navigation
Description
Summary
OpenCode Desktop shows an external_directory permission prompt when a delegated sub-agent / child session tries to access a file outside the project directory.
However, after interacting with the permission prompt, the UI repeatedly shows:
Permission request not found:
per_eb6698362001nU7yYYtuXOycSv
The delegated task remains blocked / cannot continue.
I searched for related issues around permissions, Desktop, and subagents, but I could not find an exact match for this specific combination:
- OpenCode Desktop
- delegated sub-agent / child session
external_directorypermission request- permission prompt shown in the parent UI
- permission request becomes stale / not found
- task remains blocked waiting for approval
Environment
- App: OpenCode Desktop
- OS: Windows
- UI language: Chinese
- Project worktree:
E:\0-CrewBeeLab\CrewBee
- External file/directory used for reproduction:
E:\0-CrewBeeLab\CrewBee-external-permission-demo\*
Steps to reproduce
- Open OpenCode Desktop in a project worktree:
E:\0-CrewBeeLab\CrewBee
- Create or prepare an external file outside the project worktree, for example:
E:\0-CrewBeeLab\CrewBee-external-permission-demo\demo.txt
-
From the main session, delegate a task to a sub-agent / child session.
In my case, this happened through a CrewBee delegated sub-agent flow, where the parent session asks a sub-agent to read only this external file:
E:\0-CrewBeeLab\CrewBee-external-permission-demo\demo.txt
-
The child session triggers an
external_directorypermission request. -
OpenCode Desktop displays a permission prompt in the parent UI:
需要权限
访问项目目录之外的文件
E:\0-CrewBeeLab\CrewBee-external-permission-demo\*
- Click one of the permission buttons, such as:
- 拒绝
- 始终允许
- 允许一次
Actual behavior
After clicking the permission prompt, OpenCode Desktop repeatedly shows an error toast:
请求失败
Permission request not found:
per_eb6698362001nU7yYYtuXOycSv
The delegated sub-agent task does not continue and appears to remain blocked waiting for the permission response.
Expected behavior
The permission response should be routed back to the correct child-session permission request.
After clicking:
Allow once: the child session should continue once.Allow always: the child session should continue and persist the rule.Deny: the child session should receive a denial and return a clear blocker.
The UI should not keep a stale permission prompt or repeatedly show Permission request not found.
Screenshots
Permission prompt shown for external directory access
Repeated stale permission request error
Notes / suspected area
This looks related to permission prompt routing for child sessions / subagents in OpenCode Desktop.
The request itself appears to be created and surfaced to the parent UI correctly, because the external_directory prompt is visible.
The problem seems to happen when replying to the prompt: the UI attempts to respond to a permission request id that is no longer found or not associated with the route used by the visible prompt.
Potentially related areas:
- child session / subagent permission request routing
- parent session request tree aggregation
- Desktop/Web permission prompt state
- stale permission prompt cleanup
- permission response endpoint using the wrong session/request context
This does not look like a permission rules engine issue alone, because the external_directory request is displayed correctly.
Activity
github-actions commentedon Jun 11, 2026
This issue might be a duplicate of existing issues. Please check:
Permission request not foundafter interrupted approval — same root symptom (clicking a permission prompt in Desktop/Web returns "Permission request not found" and leaves the child session blocked). That issue also has a root cause analysis and workaround discussion that likely applies here.If your issue is the same, please consider adding any new details (e.g., specific to delegated sub-agent flows or Windows) as a comment on the existing issue rather than opening a new one.
github-actions commentedon Aug 11, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.