anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[FEATURE]: Spawn a separate process for tool calls #4070

New Issue
Open
opened 2026-02-16 17:42:30 -05:00 by yindo · 3 comments
yindo commented 2026-02-16 17:42:30 -05:00
Owner
Copy Link
Copy Source

Originally created by @viraptor on GitHub (Jan 1, 2026).

Originally assigned to: @thdxr on GitHub.

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

I'd like opencode to spawn a new process to execute all tools. It could be either persistent or per-call, but having all tools executed in isolation would help with sandboxing a lot. Specifically, currently I'm running opencode with sandbox-exec which prevents reads/writes outside of the project directory. This works, but due to the complexity of opencode, the policy needs to allow all kind of things I'd rather it didn't. For example:

  • opencode logs/storage/auth
  • config directory
  • network access
  • package caches/build for node/npm
    This mostly comes up because of the ability to autoupdate and do other fancy things.

What I'd like to do is to spawn the tools manager process with a specific security policy. While this specifically solves sandbox-exec for me, it would apply in the same way to restrictions on other systems: selinux, apparmor, pledge, others. Ideally the "sandbox setup" step would be a hook available for plugins to do what they need after the code is already loaded and avoid dealing with (for example) $TMPDIR/node-compile-cache.

The communication with the new process could be done using websockets.

To avoid overhead for people who don't care, there could be a switch added for "direct" and "isolated" tool.

One tricky part is that there are tool hooks already in the code and they'd likely have to start running in the new process as well, or all the information would have to be piped to the main one.

Originally created by @viraptor on GitHub (Jan 1, 2026). Originally assigned to: @thdxr on GitHub. ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request I'd like opencode to spawn a new process to execute all tools. It could be either persistent or per-call, but having all tools executed in isolation would help with sandboxing a lot. Specifically, currently I'm running opencode with `sandbox-exec` which prevents reads/writes outside of the project directory. This works, but due to the complexity of opencode, the policy needs to allow all kind of things I'd rather it didn't. For example: - opencode logs/storage/auth - config directory - network access - package caches/build for node/npm This mostly comes up because of the ability to autoupdate and do other fancy things. What I'd like to do is to spawn the tools manager process with a specific security policy. While this specifically solves sandbox-exec for me, it would apply in the same way to restrictions on other systems: selinux, apparmor, pledge, others. Ideally the "sandbox setup" step would be a hook available for plugins to do what they need after the code is already loaded and avoid dealing with (for example) `$TMPDIR/node-compile-cache`. The communication with the new process could be done using websockets. To avoid overhead for people who don't care, there could be a switch added for "direct" and "isolated" tool. One tricky part is that there are tool hooks already in the code and they'd likely have to start running in the new process as well, or all the information would have to be piped to the main one.
yindo added the discussion label 2026-02-16 17:42:30 -05:00
yindo commented 2026-02-16 17:42:31 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Jan 1, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #2242: Is there a way to sandbox the agent ? - Similar request for restricting agent access to files outside the current directory
  • #5529: Add per-agent filesystem boundaries (allow/deny paths) + optional run-as user for bash - Comprehensive proposal for per-agent isolation and sandboxing
  • #6318: Limit tool (e.g. write, edit) permissions to specific folders - Request to limit tool permissions to specific project folders
  • #4667: Limiting access for tools in a safer way - Proposes using bubblewrap for per-agent security contexts with folder-level restrictions

Feel free to ignore if your specific use case differs (e.g., if you need persistent process isolation for plugin hooks execution).

@github-actions[bot] commented on GitHub (Jan 1, 2026): This issue might be a duplicate of existing issues. Please check: - #2242: Is there a way to sandbox the agent ? - Similar request for restricting agent access to files outside the current directory - #5529: Add per-agent filesystem boundaries (allow/deny paths) + optional run-as user for bash - Comprehensive proposal for per-agent isolation and sandboxing - #6318: Limit tool (e.g. write, edit) permissions to specific folders - Request to limit tool permissions to specific project folders - #4667: Limiting access for tools in a safer way - Proposes using bubblewrap for per-agent security contexts with folder-level restrictions Feel free to ignore if your specific use case differs (e.g., if you need persistent process isolation for plugin hooks execution).
yindo commented 2026-02-16 17:42:31 -05:00
Author
Owner
Copy Link
Copy Source

@viraptor commented on GitHub (Jan 1, 2026):

The other requests talk about more specific things, but don't really provide a framework how to achieve them well.

@viraptor commented on GitHub (Jan 1, 2026): The other requests talk about more specific things, but don't really provide a framework how to achieve them well.
yindo commented 2026-02-16 17:42:31 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Jan 1, 2026):

@viraptor we are going to have some stuff very closely related to this v soon!

@rekram1-node commented on GitHub (Jan 1, 2026): @viraptor we are going to have some stuff very closely related to this v soon!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label discussion
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#4070
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?