anomalyco / anomalyco/opencode

[FEATURE]: Provide a default pre-approved temp directory for skills/tools writing outside the workspace

Open
#48,100 3 comments 0 reactions 1 assignee View on GitHub

@kitlangton is already working on this.

Since Sep 9, 2026.

Dominant language
TypeScript
Stars
209k
Forks
27.5k
Avg merge
7h 2m
Merged PRs (30d)
384

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

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:

  1. Expose a documented, pre-approved temp directory via an environment variable (e.g. OPENCODE_TMPDIR) that tools/skills can read.
  2. Pre-approve mktemp -d / $TMPDIR writes by default (or a well-known subdir under it) instead of a single hard-coded path.
  3. 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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.