[FEATURE]: Unify shell initialization behavior between user shell and agent bash tool #17792

Activity

1. bakabaka9405

   added

   discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

   on Mar 16, 2026
2. github-actions

   assigned

   rekram1-node

   on Mar 16, 2026
3. github-actions

   added

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   on Mar 16, 2026
4. github-actions commented on Mar 16, 2026

   

   github-actionsBot

   on Mar 16, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Shell sessions losing $PATH value from parent shell #4968: Shell sessions losing $PATH from parent shell — discusses the same root cause (bash tool spawning non-interactive shells that don't source RC files like ~/.bashrc/~/.zshrc), with proposed solutions including launching interactive shells
   • PowerShell profile not loaded and inconsistent shell versions on Windows #17393: PowerShell profile not loaded and inconsistent shell versions — very similar report about shell profiles/init files not being loaded in the bash tool vs the user shell (! prefix), causing inconsistent behavior

   If your issue is substantially the same as one of these, please consider adding detail there instead.
5. zigmoo commented on Apr 29, 2026

   

   zigmoo

   on Apr 29, 2026

   Last edited by zigmoo

   More actions

   +1 on this feature request — hitting the exact same pain, but with a compounding bug that makes it worse.

   Our specific symptoms

   • Agent: OpenCode (kimi-k2.6) on Linux (Omarchy/Arch)
   • User shell (!): works fine, sources ~/.bashrc, finds all tools
   • Agent bash tool: fails to find any tools installed in PATH via ~/.bashrc

   The compounding bug: literal tilde in inherited PATH

   Not only does the agent bash tool not source ~/.bashrc, but the parent OpenCode/Electron process appears to inject a PATH containing a literal unexpanded ~/.local/bin:

   $ python3 -c 'import os; print([s for s in os.environ["PATH"].split(":") if "~" in s])'
   ['~/.local/bin']

   Bash does not expand ~ in inherited environment variables — only at the moment of export. So that segment is effectively a broken path.

   Evidence: DIL tool directory completely absent from $PATH

   (DIL Distributed Intent Ledger)

   Our ~/.bashrc adds:

   export PATH="$HOME/Documents/dil_agentic_memory_0001/_shared/scripts/bin:$PATH"

   After agent spawns bash -c:

   $ which task_tool
   # "no task_tool in (...)"
   
   $ source ~/.bashrc && which task_tool
   # /home/moo/Documents/dil_agentic_memory_0001/_shared/scripts/bin/task_tool

   Relationship to other issues

   • Shell sessions losing $PATH value from parent shell #4968 (Shell sessions losing $PATH value) — related, but about PATH being minimal, not about missing ~/.bashrc sourcing entirely.
   • Web UI - Terminal no longer sources .bashrc which doesn't load colors/aliases/history settings/etc #11634 (Web UI Terminal no longer sources .bashrc) — was fixed for the user ! shell, but the agent bash tool still doesn't source it.
   • fix: preserve nix/direnv PATH in login shell for ! commands #24246 (preserve nix/direnv PATH in login shell for ! commands) — fixed PATH preservation for ! commands, not agent bash.
   • Tilde (~) bug - is it a problem with OpenCode, or with Grok 4.1 Fast? #14559 (Tilde (~) bug) — another user hit tilde issues and noted "I'm not having this issue in claude or codex."

   Why Claude/Codex work

   They appear to spawn bash as a login shell (bash -l -c) or explicitly source ~/.bashrc, so PATH additions and function definitions are available to the agent.

   Request

   Please consider:

   1. Spawning agent bash as a login shell (bash -l -c '...') on Linux/macOS, OR
   2. Explicitly expanding tildes in inherited PATH before spawning, OR
   3. Sourcing shell init files before agent command execution.

   This would fix the disjoint between ! shell (works) and agent bash tool (broken) that #17792 identifies.

   PS: Thanks to https://github.com/bakabaka9405 for the existing Issue to Work With!
6. bakabaka9405 commented on Apr 30, 2026

   

   bakabaka9405

   on Apr 30, 2026

   Author

   More actions

   I found a temporary workaround for the current behavior by using an opencode hook to inject my PowerShell profile before every agent bash tool execution.

   // .opencode/plugins/source-before-bash.js
   export const SourceBeforeBash = async () => {
     return {
       "tool.execute.before": async (input, output) => {
         if (input.tool !== "bash") return
   
         const command = output.args?.command
         if (!command || typeof command !== "string") return
   
         const sourceFile = "C:/Users/<Username>/Documents/PowerShell/Microsoft.PowerShell_profile.ps1"
   
         if (command.includes("$env:__BASH_AUTO_INJECT")) return
   
         output.args.command =
           `. '${sourceFile}'; $env:__BASH_AUTO_INJECT = 1; ${command}`
       },
     }
   }

   This makes the agent bash tool load the same profile initialization that I expect in my normal shell session, so aliases/functions/PATH changes from my PowerShell profile become available to agent-executed commands as well.

   The $env:__BASH_AUTO_INJECT = 1 marker is necessary as a sentinel. It prevents the hook from injecting the same source command repeatedly if a command is already wrapped. It also helps when the injected command leaks into the visible tool history and the agent later copies or imitates the previous command: the hook can detect the marker and avoid a second injection. Without this guard, commands can become nested like:

   . 'profile.ps1'; . 'profile.ps1'; . 'profile.ps1'; <actual command>

   This workaround is functional, but it has two drawbacks:

   1. The injected prefix is currently visible in the command shown to the user and/or retained in the agent-visible history.
   2. That increases token usage and can encourage the agent to learn or reproduce implementation details that should ideally remain a transport/runtime concern.

   This is very close to the motivation behind #5321, where displayInput would allow a plugin to execute a wrapped command while displaying the original, unwrapped command. I agree with that direction. The hook/plugin layer would be much safer and cleaner if opencode officially supported a way for tool.execute.before hooks to distinguish between:

   • the command actually executed by the runtime, and
   • the command shown in the UI / persisted into agent-visible history.

   Related work also appears in #6927, which mentions #5321 as related to tool input/output display behavior.

   So while this hook is a usable temporary workaround, I would still prefer an official solution that either:

   • unifies shell initialization between user ! shell and agent bash tool directly, or
   • provides a documented hook/display API so wrappers can safely hide injected runtime prefixes.

   This would improve security, reduce token usage, and avoid training the agent to copy internal wrapper commands.
7. thdxr

   removed

   discussionUsed for feature requests, proposals, ideas, etc. Open discussionUsed for feature requests, proposals, ideas, etc. Open discussion

   coreAnything pertaining to core functionality of the application (opencode server stuff)Anything pertaining to core functionality of the application (opencode server stuff)

   on May 3, 2026
8. CresentMoon commented on Jun 14, 2026

   

   CresentMoon

   on Jun 14, 2026

   Last edited by CresentMoon

   More actions

   As a Simplified Chinese user on Windows, I'd like to add our pain point.

   On Windows, the system code page defaults to 936 (GBK), but most modern development tools expect UTF-8 (65001). The typical fix is adding chcp 65001 to the PowerShell profile. However, since the agent bash tool doesn't load the PowerShell profile, Chinese characters in command output become garbled. This significantly hurts the experience for Chinese-speaking developers.

   Note that enabling the "Beta: Use Unicode UTF-8 for worldwide language support" option in Windows region settings is not a viable workaround for Chinese users — it breaks text rendering in many legacy applications, causing garbled characters in non-Unicode programs. This is a well-known compatibility issue reported by many Chinese users.

   A unified shell init behavior (or at least making the ! shell and agent bash tool consistent) would resolve this and make OpenCode much more accessible to the Chinese developer community.
9. Xarianne commented on Jul 20, 2026

   

   Xarianne

   on Jul 20, 2026

   More actions

   I have ran into this issue as well (just making the interest in this fix known from another user.)
10. ch-arslanahmad commented on Sep 4, 2026

    

    ch-arslanahmad

    on Sep 4, 2026

    More actions

    For anyone waiting on this, here's a working workaround on Linux using BASH_ENV.

    1. Create ~/.config/opencode/shell-init.sh with your aliases and env:

    #!/bin/bash
    # Source whatever files define your aliases and env.
    # Only load non-interactive-safe stuff here.
    # Skip interactive tools like starship, zoxide, mise -- they break in dumb terminals.
    
    [ -f "$HOME/.bash_aliases" ] && source "$HOME/.bash_aliases"
    [ -f "$HOME/.bash_env" ] && source "$HOME/.bash_env"

    2. Create ~/.config/opencode/shell-wrapper.sh (replace path):

    #!/bin/bash
    export BASH_ENV=/home/youruser/.config/opencode/shell-init.sh
    exec /usr/bin/bash "$@"

    3. In opencode.json:

    { "shell": "/home/youruser/.config/opencode/shell-wrapper.sh" }

    4. chmod +x both files, restart OpenCode.

    ---

    Customizing shell-init.sh: Source wherever your aliases live. Locations for me:

    • ~/.bash_aliases -- standalone alias file
    • ~/.bash_env -- environment variables
    • ~/.profile or ~/.bash_profile -- PATH, login exports
    • Your distro's default alias file (e.g. /etc/skel/.bash_aliases)

    Avoid sourcing full ~/.bashrc, it usually has interactive-only stuff (prompts, completions) that errors in non-TTY context.

    ---

    Why 2 files: combining them causes an infinite loop since bash sources BASH_ENV on start.

    BASH_ENV is auto-sourced by bash in non-interactive mode in OpenCode, bypassing the ~/.bashrc interactive guard (available by default) without removing it.
11. neriousy commented on Oct 20, 2026

    

    neriousy

    on Oct 20, 2026

    Member

    More actions

    Thanks for the report — starting with OpenCode 2.0.0, user shell commands and the agent's shell tool share non-interactive startup behavior rather than explicitly sourcing different shell profiles. No opt-in is needed: ! commands and agent shell commands both use this behavior, so interactive aliases/functions should not be assumed available. Update with opencode upgrade or npm i -g @opencode/cli@latest (desktop: update the app). Please comment or reopen if the two paths still initialize differently on that version.
12. neriousy

    closed this as completedon Oct 20, 2026