Repository navigation
[FEATURE]: Add config to change shell for bash tool #4702
Description
Feature hasn't been suggested before.
- 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?
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).
Activity
[-][FEATURE]: Change shell for bash tool via config file[/-][+][FEATURE]: Add config to change shell for bash tool[/+]github-actions commentedon Nov 24, 2025
This issue might be a duplicate of existing issues. Please check:
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.
rekram1-node commentedon Nov 25, 2025
yeah gonna make this better tmr
ariane-emory commentedon 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.
rekram1-node commentedon Nov 26, 2025
I'm going to do this we are a bit opinionated with the implementation here
ariane-emory commentedon Nov 26, 2025
Great, in that case I'll leave it be.
stevoland commentedon Dec 3, 2025
Really keen to see this also for sandboxing.
Would you consider providing your rough requirements to begin a contribution?
ariane-emory commentedon 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: #4917
stevoland commentedon 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 #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
rekram1-node commentedon 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
JohnDeved commentedon Jan 20, 2026
I have opened a PR that implements this feature: #9724
It adds:
"shell"config option inopencode.jsonshell.resolveplugin hook for dynamic resolution$SHELL→ System fallbackstevoland commentedon 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:
Which could future proof it for eg: adding a description to pass to the model
JohnDeved commentedon 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:
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.
stevoland commentedon 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 😄
Merge pull request #419 from adolago/fix/openclaw-4702-issue-344
github-actions commentedon Mar 29, 2026
To stay organized issues are automatically closed after 90 days of no activity. If the issue is still relevant please open a new one.