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

[FEATURE]: Inform the model what shell it's running inside of in Bash tool's description #3185

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

Originally created by @ariane-emory on GitHub (Nov 28, 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

Frequently, I'll see my model try to use shell syntax that only works in bash. This will fail, because I'm actually running opencode from inside fish. I assume similar models probably make similar mistakes in other non-bash shells: bash is probably the shell they're most trained on, so they're taking a safe bet and reaching for it first.

Generally, the model will see the error message, figure out what shell it's actually running in, and redo the shell command using syntax that's appropriate for the fish context it's running inside of. So, it's not a showstopper.

However, it isn't ideal: it still means at least one extra turn, more time spent, more requests/tokens exchanged with the provider, and one more failed tool call cluttering up its context.

All this could be avoided, saving us time and tokens, if the model was advised ahead of time in the generated system prompts as to what shell it's running inside of instead of having to discover it by trial and error.

Originally created by @ariane-emory on GitHub (Nov 28, 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. ### Describe the enhancement you want to request Frequently, I'll see my model try to use shell syntax that only works in bash. This will fail, because I'm actually running opencode from inside fish. I assume similar models probably make similar mistakes in other non-bash shells: bash is probably the shell they're most trained on, so they're taking a safe bet and reaching for it first. Generally, the model will see the error message, figure out what shell it's actually running in, and redo the shell command using syntax that's appropriate for the fish context it's running inside of. So, it's not a showstopper. However, it isn't ideal: it still means at least one extra turn, more time spent, more requests/tokens exchanged with the provider, and one more failed tool call cluttering up its context. All this could be avoided, saving us time and tokens, if the model was advised ahead of time in the generated system prompts as to what shell it's running inside of instead of having to discover it by trial and error.
yindo added the discussion label 2026-02-16 17:39:02 -05:00
yindo commented 2026-02-16 17:39:02 -05:00
Author
Owner
Copy Link
Copy Source

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

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

  • #4683: [FEATURE]: allow multiple shell setups and allow switching them at runtime via TUI command - This issue explicitly mentions the same concern about informing the LLM what shell is being used ("Most of LLMs try to use shell syntax, is it possible to add the shell information to system prompt based on the shell?")

  • #4702: [FEATURE]: Add config to change shell for bash tool - Related to shell configuration for the bash tool

  • #3195: Dynamic system prompts for custom agents - Related to the broader feature of dynamically generating system prompts with contextual information

Feel free to ignore if your use case requires a different approach.

@github-actions[bot] commented on GitHub (Nov 28, 2025): This issue might be a duplicate of or related to existing issues. Please check: - #4683: [FEATURE]: allow multiple shell setups and allow switching them at runtime via TUI command - This issue explicitly mentions the same concern about informing the LLM what shell is being used ("Most of LLMs try to use shell syntax, is it possible to add the shell information to system prompt based on the shell?") - #4702: [FEATURE]: Add config to change shell for bash tool - Related to shell configuration for the bash tool - #3195: Dynamic system prompts for custom agents - Related to the broader feature of dynamically generating system prompts with contextual information Feel free to ignore if your use case requires a different approach.
yindo commented 2026-02-16 17:39:02 -05:00
Author
Owner
Copy Link
Copy Source

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

Upon researching a little and doing some further review of the situation, I'm coming around to the idea that putting the advice into the tool description for the 'bash' tool in the tool scheme instead of in the system prompt body proper might be a superior option: if the advice about which shell is in use is in the tool schema, the model's presented with this information right at the time when it needs to see it (when it 'reaches' for the tool), and the advice won't be resent with every single message as part of the system prompt.

@ariane-emory commented on GitHub (Nov 28, 2025): Upon researching a little and doing some further review of the situation, I'm coming around to the idea that putting the advice into the tool description for the 'bash' tool in the tool scheme instead of in the system prompt body proper might be a superior option: if the advice about which shell is in use is in the tool schema, the model's presented with this information right at the time when it needs to see it (when it 'reaches' for the tool), and the advice won't be resent with every single message as part of the system prompt.
yindo commented 2026-02-16 17:39:02 -05:00
Author
Owner
Copy Link
Copy Source

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

yeah more coming soonnnnn

this weekend ill be doing something for this

@rekram1-node commented on GitHub (Nov 28, 2025): yeah more coming soonnnnn this weekend ill be doing something for this
yindo commented 2026-02-16 17:39:02 -05:00
Author
Owner
Copy Link
Copy Source

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

Alright. I've got something for it baking presently, so we might be racing each other.

Sent from Proton Mail for Android.

-------- Original Message --------
On Friday, 11/28/25 at 17:35 Aiden Cline @.***> wrote:

rekram1-node left a comment (sst/opencode#4866)

yeah more coming soonnnnn

this weekend ill be doing something for this

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>

@ariane-emory commented on GitHub (Nov 28, 2025): Alright. I've got something for it baking presently, so we might be racing each other. Sent from [Proton Mail](https://proton.me/mail/home) for Android. -------- Original Message -------- On Friday, 11/28/25 at 17:35 Aiden Cline ***@***.***> wrote: > rekram1-node left a comment [(sst/opencode#4866)](https://github.com/sst/opencode/issues/4866#issuecomment-3590645527) > > yeah more coming soonnnnn > > this weekend ill be doing something for this > > — > Reply to this email directly, [view it on GitHub](https://github.com/sst/opencode/issues/4866#issuecomment-3590645527), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AXLUM6BVCCJB5GODCUQ3S2L37DE45AVCNFSM6AAAAACNPH7NLOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTKOJQGY2DKNJSG4). > You are receiving this because you authored the thread.Message ID: ***@***.***>
yindo commented 2026-02-16 17:39:02 -05:00
Author
Owner
Copy Link
Copy Source

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

+1 for adding something around describing the bash tool to the model. As another flavor of example, I change my $SHELL to point to a custom script that runs in a docker container with readonly access to my fs, and I add this description to my AGENTS.md so the model knows to not bother trying doing certain operations with it:

- For my own safety, I've isolated the `bash` tool to run in a docker container with the current project dir mounted as readonly:
  - So when you run shell commands, they will run in this isolated linux container that prevents changes to my project dir (code files, .git dir, etc.)
  - For anything other than the `bash` tool, I'm using the platform stated above
  - The `bash` tool works like this even in "build mode" -- this docker isolation is separate from "plan mode" vs. "build mode"

Once we get support to configure the bash tool in config instead of the $SHELL env var (https://github.com/sst/opencode/issues/4702), that might be a natural place to put certain descriptions like this. Even moreso if we get support to configure and present multiple different shell tools to the model (https://github.com/sst/opencode/issues/4683).

@jdanbrown commented on GitHub (Dec 3, 2025): +1 for adding something around describing the bash tool to the model. As another flavor of example, I change my `$SHELL` to point to a custom script that runs in a docker container with readonly access to my fs, and I add this description to my `AGENTS.md` so the model knows to not bother trying doing certain operations with it: ```md - For my own safety, I've isolated the `bash` tool to run in a docker container with the current project dir mounted as readonly: - So when you run shell commands, they will run in this isolated linux container that prevents changes to my project dir (code files, .git dir, etc.) - For anything other than the `bash` tool, I'm using the platform stated above - The `bash` tool works like this even in "build mode" -- this docker isolation is separate from "plan mode" vs. "build mode" ``` Once we get support to configure the bash tool in config instead of the `$SHELL` env var (https://github.com/sst/opencode/issues/4702), that might be a natural place to put certain descriptions like this. Even moreso if we get support to configure and present multiple different shell tools to the model (https://github.com/sst/opencode/issues/4683).
yindo commented 2026-02-16 17:39:02 -05:00
Author
Owner
Copy Link
Copy Source

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

@jdanbrown To me, the immediacy of putting it in the tool's description in the tool schema sounded like it could be valuable. If many pages of conversation have already occurred in the session and the models context is starting to get crowded, the AI might have forgotten about things I told it earlier in AGENTS.md or wherever else. But, if my understanding is correct, the AI will see the description on the tool in the tool whenever it is selecting a tool to use, so by putting the actual shell there it'll be staring the model right in its metaphorical face when it 'reaches for' the Bash tool.

This seems pretty correct so far, as this PR has been working quite well for me: I've been using this PR in my personal fork since I made it, and I haven't seen a model try to use bash syntax in fish since.

@ariane-emory commented on GitHub (Dec 3, 2025): @jdanbrown To me, the immediacy of putting it in the tool's description in the tool schema sounded like it could be valuable. If many pages of conversation have already occurred in the session and the models context is starting to get crowded, the AI might have forgotten about things I told it earlier in `AGENTS.md` or wherever else. But, if my understanding is correct, the AI will see the description on the tool in the tool whenever it is selecting a tool to use, so by putting the actual shell there it'll be staring the model right in its metaphorical face when it 'reaches for' the Bash tool. This seems pretty correct so far, as this PR has been working quite well for me: I've been using this PR in my personal fork since I made it, and I haven't seen a model try to use bash syntax in fish since.
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#3185
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?