[FEATURE]: Don't default agent scratch dir to a RAM-backed /tmp #55006

Activity

1. opencode-agent commented on Oct 13, 2026

   

   opencode-agentBot

   on Oct 13, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for the detailed write-up, @joshuaeroman!

   To restate the request: OpenCode's agent scratch dir, which the env prompt tells the model to prefer, is os.tmpdir()/opencode. On distros where /tmp is tmpfs, large downloads, archives and builds placed there use up RAM. You suggest defaulting to disk-backed storage such as $XDG_CACHE_HOME/opencode/tmp (with cleanup of old files), or at least avoiding /tmp when it is tmpfs.

   I checked the code, and it works the way you describe: the path comes from packages/util/src/global-roots.ts. Setting TMPDIR=/var/tmp is the workaround available today. This can't be done as a plugin, because the scratch path and its automatic access approval are set in core when OpenCode starts.

   Related issues:

   • fix(util): use a per-user tmp directory #52973: open PR that moves the scratch dir to a per-user path (same code, but it doesn't deal with tmpfs)
   • [FEATURE]: Each project should have a dedicated /tmp dir #49073: request for a separate tmp dir per project or session
   • [FEATURE]: Provide a default pre-approved temp directory for skills/tools writing outside the workspace #48100: request for a default pre-approved temp directory
   • agent env: /tmp/opencode advertised as writable scratch but owned by another user #44696: /tmp/opencode owned by another user

   The maintainers will consider this.
2. CerisonAutomation commented on Oct 22, 2026

   

   CerisonAutomation

   on Oct 22, 2026

   More actions

   The RAM-backed scratch directory is not only a place where agent files are written — it is also loaded as a location, so it gets its own instance of every global stdio MCP server.

   From the server log:

   message="mcp connected" server=supabase ... directory=/private/var/folders/m6/k0xt0jw57f7831mf7j2q4tqw0000gn/T/opencode
   message="mcp connected" server=caveman  ... directory=/private/var/folders/m6/k0xt0jw57f7831mf7j2q4tqw0000gn/T/opencode
   

   So the scratch dir is not only consuming RAM for its own file contents — it is a third "directory" in the per-location server fan-out described in #51003. On this machine the three active locations were:

   /Users/cb
   /private/var/folders/m6/k0xt0jw57f7831mf7j2q4tqw0000gn/T/opencode
   /Users/cb/Downloads/dyad-1.16.0
   

   and the RAM-backed one accounted for a full extra set of MCP processes (~150 MB per server set on this box).

   There is a second, larger consequence. The location watcher subscribes to the ancestor chain of every location, so this scratch path additionally pulls in the following as watched directories:

   /private
   /private/var
   /private/var/folders
   /private/var/folders/m6
   /private/var/folders/m6/k0xt0jw57f7831mf7j2q4tqw0000gn
   /private/var/folders/m6/k0xt0jw57f7831mf7j2q4tqw0000gn/T
   

   see #55937. On this machine path=/ (the filesystem root) was subscribed as well, with 3122 backend=node watcher events against 1629 backend=fs-events events — the node backend is the fallback used for exactly those ancestor paths, so it is the path that turns unrelated filesystem activity into server-side event storms.

   Making the scratch dir live on the same filesystem as the workspace, or excluding it from location discovery, would remove both the RAM pressure and the extra server instances.