detectShellProfile() falls back to ~/.bashrc on Windows, where the login shell never reads it

[CarlosWonMore]

On Windows SHELL is never set, so detectShellProfile() always falls back to ~/.bashrc. Git Bash — the shell Windows users actually run teamai's block under — starts as a login shell, and a login shell reads ~/.bash_profile, ~/.bash_login or ~/.profile, never ~/.bashrc. The block gets written, the file looks correct, and the variables are never loaded.

Filed separately at @jeff-r2026's request in #661.

Where

src/resources/env.ts:

private detectShellProfile(): string {
  const home = getUserHome();
  const shell = process.env.SHELL ?? '';

  if (shell.includes('zsh')) {
    return path.join(home, '.zshrc');
  }
  return path.join(home, '.bashrc');
}

SHELL is a POSIX convention. Windows defines it neither at the user nor the machine level, so the zsh branch is unreachable there and .bashrc is the only possible outcome.

Reproduction on Windows 11

$ node -e "console.log(JSON.stringify(process.env.SHELL))"
undefined

$ reg query HKCU\Environment | findstr /i shell
(no SHELL value)

After teamai pull with an env/env.yaml that has at least one variable, ~/.bashrc receives:

# [teamai:env:start]
# DO NOT EDIT: This section is auto-managed by teamai
[ -f "/c/Users/<user>/.teamai/env.sh" ] && source "/c/Users/<user>/.teamai/env.sh"
# [teamai:env:end]

while ~/.profile gets no block at all. The two shell types then diverge:

$ bash -lc 'echo ${MY_VAR:-<unset>}'
<unset>        # login shell — reads .bash_profile / .bash_login / .profile only

$ bash -c '. ~/.bashrc; echo ${MY_VAR:-<unset>}'
set            # the block itself is fine; it is simply never read

git-bash.exe, and Git Bash launched from Windows Terminal, pass --login, so the first case is the one users get.

Git for Windows tries to paper over this in /etc/profile.d/bash_profile.sh, but only when none of the three files exist:

if [ -e ~/.bashrc -a ! -e ~/.bash_profile -a ! -e ~/.bash_login -a ! -e ~/.profile ]; then
  # ...generates a ~/.bash_profile that sources ~/.profile and ~/.bashrc
fi

A ~/.profile is common — many installers create one, and ~/.local/bin/env adds a line to it. The moment it exists, Git for Windows does not create the .bash_profile that would have sourced .bashrc.

Why nothing catches it

doctor checks that the block is present in the profile file, and it is. Whether that file is one the user's shell actually reads is a different question, and once source is skipped there is no output at all — [ -f ... ] returns false and && short-circuits.

So the failure mode reads as success from every angle: the pull reports fine, the profile contains the block, and no variable is ever exported.

Suggested fix

Choose the profile the shell will actually read, per platform:

• Windows — prefer an existing ~/.bash_profile, then ~/.bash_login, then ~/.profile; use ~/.bashrc only when none of them exists (which is exactly the case where Git for Windows generates a .bash_profile that sources it, so both choices work).
• POSIX — keep the current SHELL-based behaviour.

If the file that ends up chosen is not one the current SHELL would read, a log.warn naming it would make the situation visible without changing the default.

Two things to keep in mind while fixing this:

1. src/uninstall.ts carries a second, independent copy of detectShellProfile() (around line 133). It has to resolve to the same file, otherwise teamai uninstall leaves a block behind — or removes the wrong one.
2. sharing.env.shellProfilePath overrides this path entirely and must keep taking precedence.

Environment

• teamai-cli 0.24.0
• Windows 11 Pro 25H2, Git for Windows 2.45.2 (git-bash.exe, launched with --login)
• ~/.bashrc present, ~/.bash_profile absent, ~/.profile present (two lines, no teamai block)

[CarlosWonMore]

Status: the fix has landed in main, but two loose ends

1. This issue never closed because the PR body has no closing keyword

#693 was merged at 2026-09-21 18:08 (UTC+8) as cc3887181 — fix(env): detect the right shell profile file on Windows (#682) (#693). The PR body only says "Filed as #682." and contains no Fixes #682 / Closes #682 keyword, so GitHub never linked the two and this issue is still open with zero comments.

The order-based fallback to .bashrc described here is gone from detectShellProfile(), so this can be closed. Either add the keyword to the PR, or close it manually — noting point 2 first.

2. ⚠️ main took 02c93fe, which carries a P1 that was fixed one minute too late

The merge squashed @STiFLeR7's ninth commit, 02c93fe. One minute before it landed, the review bot flagged src/utils/shell-profile.ts:227:

resolveActiveShellProfile() prioritizes any existing TeamAI block over the profile the current shell actually reads. For the exact upgrade case—Windows with .profile present and an old TeamAI block in .bashrc—the scan returns .bashrc before reaching .profile. Consequently, pull keeps updating the unread file and doctor incorrectly reports success.

The author agreed ("Good catch — real, serious bug") and fixed it in 1ed0141 — start from detectShellProfile's order-based pick, and only diverge from it when that pick's own content references another candidate by a home-relative path. That commit is reachable on the branch, but it landed after the merge, so main's history does not contain it (checked via the API, not from a local clone).

This is not hypothetical — it is the exact state of the machine these reports came from. Windows 11 25H2 + Git for Windows, where ~/.bashrc carries a pre-#661 teamai block spelled in the MSYS drive form (/c/Users/…) and ~/.profile exists without a teamai block. Login shells — including the bash -lc form teamai's own hooks use — read .profile only.

build	behaviour on ".profile present + stale .bashrc block"
0.25.0-beta.4 (before #693)	doctor fails, with an imprecise reason
current main (02c93fe)	pull keeps writing the unread .bashrc; doctor reports success
with 1ed0141 (per the author's description, not yet on main)	picks .profile, and surfaces the leftover as its own separate check

So for anyone who upgrades while already in that state, main is a regression in detection: the symptom stops being visible rather than being repaired.

A follow-up PR carrying 1ed0141 would close that gap — and putting Fixes #682 in it would let this issue close by itself. I'm happy to re-run the same real-machine fixture (both legacy spellings, .profile present, stale block deliberately left in place, fresh $HOME + local git team repo) against that PR as soon as it exists.

[STiFLeR7]

Confirmed — checked `origin/main` directly and you're right, it's pinned to `02c93fe`, not `1ed0141`. Apologies for the gap.

Opened #715: `1ed0141` cherry-picked cleanly onto current `main` (no conflicts — nothing merged since #693 touched the affected files), re-verified end-to-end against the exact scenario you described (scratch `$HOME`, real local git team repo, unread pre-#682 block in `.bashrc`, empty `.profile`). `pull` now writes into `.profile` and flags `.bashrc` as a non-blocking stale leftover; `doctor` reports delivery healthy. Also re-checked the Git-for-Windows forwarding case from #693 for no regression.

This one has `Fixes #682` in the body, so it should close this issue automatically on merge. Would appreciate it if you're able to re-run your hardware fixture (both legacy spellings, `.profile` present, stale block left in place) against #715 — you offered, and it's the strongest signal here given it's your reported machine state.