Repository navigation
[FEATURE]: include the resolved working directory in shell permission requests #53118
Description
Feature hasn't been suggested before.
- I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
When the shell tool asks for permission, the request carries the command but not the folder it will run in. The tool resolves that folder (workdir, or the session directory) in prepare, but permission.assert does not send it (packages/core/src/tool/plugin/shell.ts:117-141 at v2.0.22).
The same command does different things in different folders, for example rm -rf build, so a person approving it needs both. Today a client can only guess the folder from the tool input, which duplicates the engine's own resolution.
Proposal: add the resolved folder to the shell permission request, for example metadata: { cwd: target.absolute }, so pending-request reads and permission events carry it.
Environment: opencode 2.0.22 (opencode serve) with a web and desktop client built on the server API, macOS 27 (arm64). It affects every client that shows shell permission prompts (TUI, Desktop, web).
Related: #50234 covers the opposite gap: the folder is shown, but not the command.
Activity
[-]shell: include the resolved working directory in the permission request[/-][+][FEATURE]: include the resolved working directory in shell permission requests[/+]github-actions commentedon Oct 4, 2026
Thanks for updating the issue with the requested feature details and system information!
opencodejr commentedon Oct 27, 2026
Thanks for the clear write-up, @Skeptomenos! You're asking for the shell tool's permission request to include the resolved working directory (for example
metadata: { cwd: target.absolute }), so clients can show where a command will run without redoing the engine's own path resolution.I checked the code: in
packages/core/src/tool/plugin/shell.ts(v2.0.22 and currentdev),prepareresolves the folder but sends nometadatatopermission.assert. Other tools already pass metadata to permission requests (the write tool sends a file preview, for example), so this would fit the existing design. Maintainers will consider it.Related: