Fixing VS Code's Integrated Terminal Not Loading Shell Aliases and Functions From .bashrc or .zshrc

The Problem

A custom alias — alias ll="ls -la", a project-specific shortcut, a shell function wrapping a common command — is defined in ~/.bashrc or ~/.zshrc and works correctly every time it's typed in a regular terminal application (Terminal.app, GNOME Terminal, Windows Terminal with WSL). Typing the exact same alias inside VS Code's own integrated terminal panel, however, returns "command not found," as if the alias was never defined at all — despite the terminal clearly running the same shell, on the same machine, with access to the same home directory.

Why It Happens

Whether a shell reads .bashrc at all depends on whether it's launched as an interactive, non-login shell — and that's not always what VS Code starts

Bash's own startup behavior differentiates between several shell types — login versus non-login, interactive versus non-interactive — and each combination reads a different, specific set of startup files. ~/.bashrc is read by interactive, non-login shells; a login shell instead reads ~/.bash_profile (or similar), and non-interactive shells typically read neither by default. If VS Code's configuration for the integrated terminal starts a shell type that doesn't match the specific one the alias was defined under, the file containing the alias is simply never sourced.

Zsh has a parallel but differently-named set of startup files, and the same category of mismatch applies

Zsh reads ~/.zshrc for interactive shells and ~/.zprofile for login shells, following its own separate convention distinct from Bash's. A function or alias placed in the wrong one of these for the specific shell-launch mode VS Code's terminal actually uses produces the exact same category of "defined but never read" gap as the Bash case, just under different filenames.

VS Code's own terminal profile settings can explicitly configure shell arguments that change this behavior from the OS default

Beyond the shell's own default startup-file rules, VS Code's terminal.integrated.profiles settings let a specific shell launch with explicit arguments — including flags that force or suppress login-shell behavior. A profile configured (deliberately or by an inherited default) with arguments that don't match what the alias-containing startup file expects produces this same symptom even on a system where the plain shell defaults would otherwise have worked.

The Fix

1. Confirm which shell type VS Code's integrated terminal is actually launching

# Run inside the VS Code integrated terminal itself:
echo $0        # shows the shell and sometimes a leading "-" indicating a login shell
shopt login_shell 2>/dev/null  # bash-specific: reports on/off directly

Checking the actual shell mode from inside the terminal in question, rather than assuming it matches a regular terminal application's defaults, replaces a guess with the concrete fact needed to know which startup file is actually expected to be read in this specific context.

2. Explicitly source the file containing the alias from whichever startup file VS Code's shell mode does read

# In ~/.bash_profile (read by login shells), explicitly pull in .bashrc:
if [ -f ~/.bashrc ]; then
  source ~/.bashrc
fi

Rather than relocating every alias and function to a different file, having the file VS Code's shell mode actually reads explicitly source the one containing the existing aliases is a minimal, low-risk fix that works regardless of which specific combination of login/interactive mode is in play, and doesn't disturb the setup for other terminal applications that already work correctly.

3. Configure VS Code's terminal profile to launch the shell in the specific mode the alias file expects

// settings.json
"terminal.integrated.profiles.osx": {
  "bash-login": {
    "path": "bash",
    "args": ["-l"] // explicitly force a login shell
  }
},
"terminal.integrated.defaultProfile.osx": "bash-login"

Explicitly configuring the shell launch arguments — forcing a login shell with -l, for instance, if the aliases live in a file only login shells read — gives direct control over which startup files get sourced inside VS Code's terminal specifically, independent of whatever VS Code's own default profile happens to use.

4. Reload the VS Code window after any shell-profile or dotfile change, rather than assuming an existing terminal panel picks it up

Command Palette -> "Developer: Reload Window", or close and reopen
the integrated terminal panel specifically — an existing terminal
instance was already launched under the old configuration and won't
retroactively apply a settings or dotfile change.

An integrated terminal panel that's already open was launched once, under whatever configuration was active at that moment; changing a setting or a dotfile afterward has no effect on that already-running shell process, so testing a fix requires a genuinely new terminal instance rather than retyping a command in the same stale panel.

Why This Works

Each fix targets a different point in the same underlying mismatch between which startup file a given shell-launch mode reads and which file the alias actually lives in. Checking the actual shell mode replaces an assumption with a concrete fact about what VS Code's terminal is actually doing. Explicitly sourcing the alias file from whatever file is read is a low-risk fix that works regardless of the specific mode. Configuring the terminal profile's launch arguments provides direct control when the mismatch should be resolved from the VS Code side instead. And reloading or reopening the terminal ensures the fix is actually tested against a freshly-launched shell rather than a stale one that predates the change.

Conclusion

An alias or shell function that works everywhere except VS Code's integrated terminal isn't a VS Code bug — it's a mismatch between which startup file the specific shell-launch mode VS Code uses actually reads, and which file the alias happens to be defined in, following the same login/interactive distinction every shell has always had. Confirm which shell mode is actually in play from inside the terminal itself, have the relevant startup file explicitly source the one containing the alias, configure the terminal profile's launch arguments directly if the mismatch needs resolving from VS Code's side, and test any fix against a newly-launched terminal rather than one that predates the change.