You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[FEATURE]: Provide a default pre-approved temp directory for skills/tools writing outside the workspace #48100
I have verified this feature I'm about to request hasn't been suggested before.
Describe the enhancement you want to request
Problem
Skills and tools often need to write temporary artifacts outside the workspace (for example, creating a temporary git worktree via mktemp -d to keep the user's working tree read-only, or staging scratch files during a multi-step task).
opencode currently pre-approves a single, machine/user-specific path (e.g. /var/folders/kc/.../T/opencode) for external directory access. A portable skill cannot know that path ahead of time, so it falls back to mktemp -d (or $TMPDIR), which lands outside the pre-approved area and triggers a permission prompt — or is blocked.
The same skill runs without friction in other coding agents that don't restrict temp paths.
Request
Make a standard temp location the default behavior so skills don't need per-agent workarounds. For example:
Expose a documented, pre-approved temp directory via an environment variable (e.g. OPENCODE_TMPDIR) that tools/skills can read.
Pre-approve mktemp -d / $TMPDIR writes by default (or a well-known subdir under it) instead of a single hard-coded path.
Keep it portable and per-user, so a skill can just use the default mktemp -d without hard-coding a machine-specific path.
Why it matters
Multi-agent skills should not need opencode-specific branches. A standard, always-available temp dir keeps skills portable and removes an avoidable permission prompt.
Reacted by Wahlburg, acziryak-everhealth, R Gibim and Vlad Ionescu
Feature requests must use the feature request issue template, which requires a title prefixed with [FEATURE]: and includes a verification checkbox confirming you've searched for existing issues.
Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
changed the title [-]Provide a default pre-approved temp directory for skills/tools writing outside the workspace[/-][+][FEATURE]: Provide a default pre-approved temp directory for skills/tools writing outside the workspace[/+]on Sep 9, 2026
Thanks for updating the issue! It now follows the feature request template with the [FEATURE]: title prefix, verification checkbox, and a clear description of the problem and proposed solution. The label has been removed.
Adding a few findings after checking the source — the gap turns out to be narrower than it looks, and one detail matters for anyone reaching for a config rule today.
{env:VAR} does substitute inside permission patterns. Config substitution runs over the whole file, so "{env:TMPDIR}/opencode/**": "allow" is accepted and expands. Two catches:
On macOS TMPDIR ends with a separator (/var/folders/…/T/), so the pattern becomes …/T//opencode/** — a double slash that does not match the real …/T/opencode/… path (the matcher compares wildcards literally).
When TMPDIR is unset it substitutes to an empty string, so there is no fallback for a platform whose temp dir is /tmp.
A small plugin avoids both, since os.tmpdir() returns the same directory without the trailing separator, and the config(cfg) hook runs once on init with the live merged config:
That is what shipped in the project where we hit this; the effect is verifiable rather than assumed — ~/.local/share/opencode/log/opencode.log records each evaluation, and the injected rule shows as the matched action.pattern.
So two small fixes would make the <tmpdir>/opencode path the issue names expressible without a plugin: a {env:VAR:-default} form for the unset case, and normalizing a trailing separator in the substitution for the macOS case. The remaining ask here (an out-of-the-box pre-approved temp dir, exposed portably) still stands on its own.
You're asking for a standard, documented temp location that skills and tools can find and write to without a permission prompt. Examples are an OPENCODE_TMPDIR environment variable, or making mktemp -d / $TMPDIR land in the pre-approved directory. That way portable skills don't need opencode-specific branches.
Your reading of the current behaviour is right. The pre-approved directory is opencode's own tmp root, under the system temp directory. The only place it's surfaced is the instruction given to the model. Shell commands don't get it as an environment variable and TMPDIR doesn't point to it, so mktemp -d ends up outside it and triggers the external_directory prompt.
In the meantime, you can allow the system temp directory yourself with an external_directory allow rule in your permission config. That only helps on your own machine, though, not for skills shared with others.
I've marked this as a feature request for the maintainers to consider.
Activity
github-actions commentedon Sep 9, 2026
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
[FEATURE]:and includes a verification checkbox confirming you've searched for existing issues.Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
If you believe this was flagged incorrectly, please let a maintainer know.
[-]Provide a default pre-approved temp directory for skills/tools writing outside the workspace[/-][+][FEATURE]: Provide a default pre-approved temp directory for skills/tools writing outside the workspace[/+]github-actions commentedon Sep 9, 2026
Thanks for updating the issue! It now follows the feature request template with the
[FEATURE]:title prefix, verification checkbox, and a clear description of the problem and proposed solution. The label has been removed.aanbrn commentedon Sep 14, 2026
Adding a few findings after checking the source — the gap turns out to be narrower than it looks, and one detail matters for anyone reaching for a config rule today.
{env:VAR}does substitute inside permission patterns. Config substitution runs over the whole file, so"{env:TMPDIR}/opencode/**": "allow"is accepted and expands. Two catches:TMPDIRends with a separator (/var/folders/…/T/), so the pattern becomes…/T//opencode/**— a double slash that does not match the real…/T/opencode/…path (the matcher compares wildcards literally).TMPDIRis unset it substitutes to an empty string, so there is no fallback for a platform whose temp dir is/tmp.A small plugin avoids both, since
os.tmpdir()returns the same directory without the trailing separator, and theconfig(cfg)hook runs once on init with the live merged config:That is what shipped in the project where we hit this; the effect is verifiable rather than assumed —
~/.local/share/opencode/log/opencode.logrecords each evaluation, and the injected rule shows as the matchedaction.pattern.So two small fixes would make the
<tmpdir>/opencodepath the issue names expressible without a plugin: a{env:VAR:-default}form for the unset case, and normalizing a trailing separator in the substitution for the macOS case. The remaining ask here (an out-of-the-box pre-approved temp dir, exposed portably) still stands on its own.Record the upstream-report practice, and park the reference-report id…
opencodejr commentedon Oct 28, 2026
Thanks for the clear write-up, @spartan-suale!
You're asking for a standard, documented temp location that skills and tools can find and write to without a permission prompt. Examples are an
OPENCODE_TMPDIRenvironment variable, or makingmktemp -d/$TMPDIRland in the pre-approved directory. That way portable skills don't need opencode-specific branches.Your reading of the current behaviour is right. The pre-approved directory is opencode's own tmp root, under the system temp directory. The only place it's surfaced is the instruction given to the model. Shell commands don't get it as an environment variable and
TMPDIRdoesn't point to it, somktemp -dends up outside it and triggers theexternal_directoryprompt.In the meantime, you can allow the system temp directory yourself with an
external_directoryallow rule in your permission config. That only helps on your own machine, though, not for skills shared with others.I've marked this as a feature request for the maintainers to consider.