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

[FEATURE]: Add config to change shell for bash tool #3096

New Issue
Open
opened 2026-02-16 17:38:36 -05:00 by yindo · 13 comments
yindo commented 2026-02-16 17:38:36 -05:00
Owner
Copy Link
Copy Source

Originally created by @jdanbrown on GitHub (Nov 24, 2025).

Originally assigned to: @rekram1-node 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 see that I can configure the shell used by the bash tool with the SHELL env var, But it'd be helpful to be able to configure it via the config file as well.

In my case, I want to change the shell to a docker run on a readonly fs so I can safely set "bash": "allow" instead of having to approve a bunch of shell commands all the time, and this wouldn't make any sense as my global $SHELL since it's something I only want opencode to use.

I can of course make shell aliases and stuff, but it seems like opencode.jsonc is the most natural place to keep it (and go looking for it later).

Originally created by @jdanbrown on GitHub (Nov 24, 2025). Originally assigned to: @rekram1-node on GitHub. ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. - I see this feature addition from 2025-05-16, but I think it got lost in the 0.x → 1.0 migration? - https://github.com/sst/opencode/pull/23 ### Describe the enhancement you want to request I see that I can configure the shell used by the bash tool with the `SHELL` env var, But it'd be helpful to be able to configure it via the config file as well. - https://github.com/sst/opencode/blob/125af820/packages/opencode/src/tool/bash.ts#L62 In my case, I want to change the shell to a `docker run` on a readonly fs so I can safely set `"bash": "allow"` instead of having to approve a bunch of shell commands all the time, and this wouldn't make any sense as my global `$SHELL` since it's something I only want opencode to use. I can of course make shell aliases and stuff, but it seems like opencode.jsonc is the most natural place to keep it (and go looking for it later).
yindo added the discussion label 2026-02-16 17:38:36 -05:00
yindo commented 2026-02-16 17:38:37 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 24, 2025):

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

  • #4683: [FEATURE]: allow multiple shell setups and allow switching them at runtime via TUI command

Both issues request the ability to configure the shell used by the bash tool via opencode.jsonc. While #4683 proposes a more comprehensive multi-shell solution with Windows-specific support, it addresses the same core need of your feature request.

Feel free to ignore if your use case requires a simpler implementation than what's proposed in #4683.

@github-actions[bot] commented on GitHub (Nov 24, 2025): This issue might be a duplicate of existing issues. Please check: - #4683: [FEATURE]: allow multiple shell setups and allow switching them at runtime via TUI command Both issues request the ability to configure the shell used by the bash tool via opencode.jsonc. While #4683 proposes a more comprehensive multi-shell solution with Windows-specific support, it addresses the same core need of your feature request. Feel free to ignore if your use case requires a simpler implementation than what's proposed in #4683.
yindo commented 2026-02-16 17:38:37 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 24, 2025):

yeah gonna make this better tmr

@rekram1-node commented on GitHub (Nov 24, 2025): yeah gonna make this better tmr
yindo commented 2026-02-16 17:38:37 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Nov 26, 2025):

@rekram1-node Any headway on this? If not, I'd be happy to try taking a stab at it. Let me know if you have an preferences about what config property is used.

@ariane-emory commented on GitHub (Nov 26, 2025): @rekram1-node Any headway on this? If not, I'd be happy to try taking a stab at it. Let me know if you have an preferences about what config property is used.
yindo commented 2026-02-16 17:38:37 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 26, 2025):

I'm going to do this we are a bit opinionated with the implementation here

@rekram1-node commented on GitHub (Nov 26, 2025): I'm going to do this we are a bit opinionated with the implementation here
yindo commented 2026-02-16 17:38:37 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Nov 26, 2025):

Great, in that case I'll leave it be.

@ariane-emory commented on GitHub (Nov 26, 2025): Great, in that case I'll leave it be.
yindo commented 2026-02-16 17:38:37 -05:00
Author
Owner
Copy Link
Copy Source

@stevoland commented on GitHub (Dec 3, 2025):

Really keen to see this also for sandboxing.

Would you consider providing your rough requirements to begin a contribution?

@stevoland commented on GitHub (Dec 3, 2025): Really keen to see this also for sandboxing. Would you consider providing your rough requirements to begin a contribution?
yindo commented 2026-02-16 17:38:37 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Dec 3, 2025):

@stevoland I do have a PR that automatically includes the actual shell in use in the Bash tool's description, but it sounds like the maintainers may prefer a different, configuration-based approach, I'm not sure: https://github.com/sst/opencode/pull/4917

@ariane-emory commented on GitHub (Dec 3, 2025): @stevoland I do have a PR that automatically includes the actual shell in use in the Bash tool's description, but it sounds like the maintainers may prefer a different, configuration-based approach, I'm not sure: https://github.com/sst/opencode/pull/4917
yindo commented 2026-02-16 17:38:37 -05:00
Author
Owner
Copy Link
Copy Source

@stevoland commented on GitHub (Dec 3, 2025):

@ariane-emory tool description is somewhat related but I referring to this issue: "Add config to change shell for bash tool", ie: resurrecting something like the previous thing to configure the shell https://github.com/sst/opencode/pull/23

It would help us to adopt in enterprise type org with proper sandboxing of the shell via config rather than forcing our devs to run some wrapper thing/fork

@stevoland commented on GitHub (Dec 3, 2025): @ariane-emory tool description is somewhat related but I referring to this issue: "Add config to change shell for bash tool", ie: resurrecting something like the previous thing to configure the shell https://github.com/sst/opencode/pull/23 It would help us to adopt in enterprise type org with proper sandboxing of the shell via config rather than forcing our devs to run some wrapper thing/fork
yindo commented 2026-02-16 17:38:37 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Dec 3, 2025):

wow you dug into the archives for that PR reference haha

im doing something for this today so any feedback/suggestion/requests you have drop em here as you have been

@rekram1-node commented on GitHub (Dec 3, 2025): wow you dug into the archives for that PR reference haha im doing something for this today so any feedback/suggestion/requests you have drop em here as you have been
yindo commented 2026-02-16 17:38:37 -05:00
Author
Owner
Copy Link
Copy Source

@JohnDeved commented on GitHub (Jan 20, 2026):

I have opened a PR that implements this feature: #9724

It adds:

  • "shell" config option in opencode.json
  • shell.resolve plugin hook for dynamic resolution
  • Priority chain: Config → Plugin → $SHELL → System fallback
@JohnDeved commented on GitHub (Jan 20, 2026): I have opened a PR that implements this feature: #9724 It adds: - `"shell"` config option in `opencode.json` - `shell.resolve` plugin hook for dynamic resolution - Priority chain: Config → Plugin → `$SHELL` → System fallback
yindo commented 2026-02-16 17:38:37 -05:00
Author
Owner
Copy Link
Copy Source

@stevoland commented on GitHub (Jan 24, 2026):

@JohnDeved thanks for the PR, I was going to raise one myself this week.

The desktop app makes this feature more important as overriding the shell can't be done with a simple wrapper script.

Considering the strain the maintainers are under atm, I wonder if leaving the plugin changes to a separate PR might give a smaller focused PR more chance of merging?

I may still raise a PR myself, hope you don't mind. Thinking of config something like:

shell?: {
  command: string[]
}

Which could future proof it for eg: adding a description to pass to the model

@stevoland commented on GitHub (Jan 24, 2026): @JohnDeved thanks for the PR, I was going to raise one myself this week. The desktop app makes this feature more important as overriding the shell can't be done with a simple wrapper script. Considering the strain the maintainers are under atm, I wonder if leaving the plugin changes to a separate PR might give a smaller focused PR more chance of merging? I may still raise a PR myself, hope you don't mind. Thinking of config something like: ``` shell?: { command: string[] } ``` Which could future proof it for eg: adding a description to pass to the model
yindo commented 2026-02-16 17:38:37 -05:00
Author
Owner
Copy Link
Copy Source

@JohnDeved commented on GitHub (Jan 26, 2026):

@stevoland thanks for taking a look.

my thought behind the plugin support was that it could allow somewhat easy plug-and-play sandbox env plugins.
or plugins that allow other development environments without the user having to think that much about configuration themselfs.

Also +1 on your proposed shape; What do you think, I could switch to something like:

shell?: { command: string[] } | string[] | string

This would still be more future-proof while at the same time keeping simplicity.
my pr was just a rough outline. I'm willing to change it however the maintainers and community see it fit

If you still want to open your own PR, no worries at all.

@JohnDeved commented on GitHub (Jan 26, 2026): @stevoland thanks for taking a look. my thought behind the plugin support was that it could allow somewhat easy plug-and-play sandbox env plugins. or plugins that allow other development environments without the user having to think that much about configuration themselfs. Also +1 on your proposed shape; What do you think, I could switch to something like: ```ts shell?: { command: string[] } | string[] | string ``` This would still be more future-proof while at the same time keeping simplicity. my pr was just a rough outline. I'm willing to change it however the maintainers and community see it fit If you still want to open your own PR, no worries at all.
yindo commented 2026-02-16 17:38:37 -05:00
Author
Owner
Copy Link
Copy Source

@stevoland commented on GitHub (Jan 26, 2026):

@JohnDeved that makes sense - we would also love the plugin support.

I took a 2nd look at yours and the diff looks good - I've nothing to add. Just really hope something gets merged 😄

@stevoland commented on GitHub (Jan 26, 2026): @JohnDeved that makes sense - we would also love the plugin support. I took a 2nd look at yours and the diff looks good - I've nothing to add. Just really hope something gets merged 😄
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#3096
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?