fix(env): detect the right shell profile file on Windows (#682)

[STiFLeR7]

Problem

detectShellProfile() reads SHELL to decide between .zshrc and .bashrc. SHELL is never set on Windows, so it always falls back to ~/.bashrc — but Git Bash starts as a login shell, which reads ~/.bash_profile, ~/.bash_login or ~/.profile, never ~/.bashrc.

teamai pull reports success, the block is written and looks correct on inspection, but no shell ever sources it. Nothing catches it: doctor only checks that the block is present in the profile file, not whether that file is one the shell actually reads.

Filed as #682.

Fix

• New src/utils/shell-profile.ts with the platform-aware logic:
  • win32: prefer an existing ~/.bash_profile, then ~/.bash_login, then ~/.profile, in that order; fall back to ~/.bashrc only when none exist — matching Git for Windows' own fallback in /etc/profile.d/bash_profile.sh, so both agree on what actually gets sourced.
  • POSIX: unchanged SHELL-based behavior.
• platform is an injectable parameter (default process.platform), same convention as resolveCliPath in utils/cli-path.ts — CI only runs ubuntu/macos, so a hardcoded process.platform would leave the win32 branch permanently untested, which is how this went unnoticed in the first place.
• EnvHandler.detectShellProfile (resources/env.ts) and the standalone copy in uninstall.ts both now delegate to this single implementation, instead of carrying two independent copies that could silently drift and leave pull and uninstall disagreeing on which file to touch.
• sharing.env.shellProfilePath (the team-config override) is untouched — it already short-circuits before detectShellProfile() is called.

Test Plan

Unit tests (npx vitest run) — all passing:

• New src/__tests__/shell-profile.test.ts: POSIX zsh/bash/unset-SHELL cases, and the win32 priority order (.bash_profile > .bash_login > .profile > .bashrc fallback), including the exact file combination reported in detectShellProfile() falls back to ~/.bashrc on Windows, where the login shell never reads it #682.
• Updated env-handler.test.ts / uninstall.test.ts to pin process.platform to 'linux' for their existing SHELL-based assertions, since I ran the full suite on an actual Windows dev machine and these tests otherwise silently started exercising the new win32 branch instead of the POSIX one they're meant to test (same reasoning as the platform injection above — this is precisely the coverage gap that let detectShellProfile() falls back to ~/.bashrc on Windows, where the login shell never reads it #682 through).
• npx tsc --noEmit: clean.

Real CLI, end-to-end (npm run build, then drove the built dist/index.js against a real local git team repo with HOME/USERPROFILE pointed at sandboxed fixtures — Windows-native paths, not Git Bash /tmp/... paths, which native Windows Node does not resolve):

1. Exact repro from detectShellProfile() falls back to ~/.bashrc on Windows, where the login shell never reads it #682 (~/.bashrc present, ~/.bash_profile absent, ~/.profile present): teamai pull now injects into .profile, leaves .bashrc untouched.
2. No login-shell file exists: teamai pull creates and injects into .bashrc (matches Git for Windows' own fallback).
3. Both .bash_profile and .bashrc exist: teamai pull prefers .bash_profile, leaves .bashrc untouched.
4. teamai doctor reports "Env variables injected in shell profile" as healthy against scenario 3.
5. teamai uninstall --force against scenario 3 correctly finds and cleans the block from .bash_profile (not .bashrc) — confirming pull/doctor/uninstall now agree on the same file, per the concern raised in the issue about the previously-duplicated logic.

Note for reviewers

While running the full suite on Windows I found 30 pre-existing test files (70 tests, e.g. doctor-env-delivery.test.ts, search-index-multi.test.ts, source.test.ts) that fail on an actual Windows host due to hardcoded POSIX path separators/characters in test fixtures — confirmed present on unmodified main via git stash (identical failure count before/after this change). Unrelated to this fix and invisible on the ubuntu/macos-only CI; flagging in case it's useful, happy to open a separate issue if not already tracked.

Co-Authored-By: Claude Sonnet 5 noreply@anthropic.com

[github-actions]

• [P1 blocking] src/uninstall.ts:513 only checks the newly selected profile. In the reported upgrade scenario, an existing TeamAI block remains in .bashrc, while the next pull adds another block to .profile; uninstall then cleans only .profile and leaves the managed .bashrc block behind. Discovery/removal should also migrate or scan legacy candidate profiles.
• [P1 blocking] src/utils/shell-profile.ts:33 ignores SHELL entirely on Windows. Native Node launched from MSYS/Cygwin with SHELL=/usr/bin/zsh previously selected .zshrc; this change redirects it to a Bash profile, so the environment is no longer loaded. Preserve explicit zsh detection before applying the Git Bash fallback.
• The PR description includes a detailed test plan and real-CLI end-to-end verification record; no testing-description finding.

[STiFLeR7]

Addressed both P1s in 7c1659b:

• shell-profile.ts:33 (zsh on Windows): SHELL is now checked before the platform branch, on every platform, so a zsh installed via MSYS2/Cygwin (which sets SHELL just like on POSIX, even though native Windows Node still reports platform === 'win32') resolves to .zshrc again. The Windows bash-profile-priority branch only applies when SHELL doesn't indicate zsh.
• uninstall.ts:513 (stale legacy block left behind): buildRemovalPlan now scans every profile file teamai could ever have written to (.zshrc, .bashrc, .bash_profile, .bash_login, .profile, plus a configured override) and cleans every one still carrying a TEAMAI_ENV_START block, instead of only the one detectShellProfile() resolves to today. This covers exactly the upgrade path described: a stale block in .bashrc from an older CLI survives alongside a freshly-written block in .profile, and uninstall now removes both.

Both verified with unit tests (new cases in shell-profile.test.ts and uninstall.test.ts) and a real CLI build reproducing each scenario end-to-end (zsh-on-Windows via SHELL, and the stale-.bashrc-plus-fresh-.profile migration case, confirming uninstall now cleans both files and preserves surrounding user content in each).

[github-actions]

• [P1 blocking] src/uninstall.ts:525 — Scanning every standard profile and deleting any TeamAI marker can remove another active scope’s env block. For example, uninstalling a project-scoped setup configured for .profile also removes a user-scoped block from .bashrc. Limit cleanup to blocks sourcing the current getDataHome(localConfig)/env.sh, rather than matching the global marker alone.
• [P1 blocking] src/utils/shell-profile.ts:36 — This changes documented user-facing profile selection and uninstall behavior, but no documentation was updated. The repository rules require behavior changes to update all affected bilingual docs; at minimum the configuration/env and uninstall sections in docs/usage-guide.md and docs/usage-guide.zh-CN.md need synchronized updates.

The PR description includes unit/type-check results and a concrete real-CLI end-to-end record, so it does not lack a test plan or e2e notes.

[STiFLeR7]

Addressed both new P1s in 4043f69:

• uninstall.ts:525 (scope isolation): a candidate profile file now only counts if its block's source line actually points at this scope's own env.sh (getDataHome(localConfig)/env.sh), not merely whether it carries the generic TEAMAI_ENV_START marker. Reused the same block-parsing check doctor already relies on (moved extractEnvBlock/envBlockSourcesPath out of doctor-delivery.ts into the shared utils/shell-profile.ts so there's one implementation, not two that could drift like detectShellProfile itself did in detectShellProfile() falls back to ~/.bashrc on Windows, where the login shell never reads it #682). Added a unit test + real-CLI verification: an unrelated scope's block in .bashrc now survives an uninstall that only touches its own .profile block.
• shell-profile.ts:36 (docs): added the Windows shell-profile selection order to docs/usage-guide.md / usage-guide.zh-CN.md's Env section, and updated the Uninstall section's "what gets removed" bullet to describe the scoped multi-file cleanup.

All three rounds of fixes re-verified together: unit tests pass (npx vitest run, same pre-existing unrelated Windows-host failures as baseline — confirmed via git stash earlier in the thread), npx tsc --noEmit clean, and a fresh real-CLI build re-run through all scenarios (original #682 repro, no-file fallback, .bash_profile priority, zsh-on-Windows via SHELL, same-scope stale-block migration, and cross-scope isolation).

[github-actions]

• [P1 blocking] envBlockSourcesPath() searches for the raw path, but generateShellBlock() shell-escapes apostrophes as '\''. For a valid home/project path such as /home/O'Brien/.teamai/env.sh, doctor incorrectly reports the generated block as broken and uninstall fails to remove it. Compare against the same shell-quoted representation used by the generator and add an apostrophe-path regression test. src/utils/shell-profile.ts:85
• The PR description includes sufficient unit, type-check, and real-CLI end-to-end verification records.

[STiFLeR7]

Addressed the P1 in a983ef0:

• shell-profile.ts:85 (apostrophe-quoted paths): envBlockSourcesPath now first checks whether the block contains shellQuoteValue(posixPath) — the exact string generateShellBlock actually writes — before falling back to the looser raw/quoted checks. Moved shellQuoteValue out of resources/env.ts into the shared utils/shell-profile.ts (env.ts now imports it) so the comparison uses the generator's real escaping rule instead of re-deriving it a second time, which is the same class of drift risk this whole thread has been closing. Added unit tests covering the apostrophe case (/home/O'Brien/.teamai/env.sh), a plain path, a non-matching path, and the pre-existing [bug] Windows: env 注入到 shell profile 时写的是原生路径，source 静默失败而 doctor 仍报通过 #661 unquoted-Windows-path case — all built with the real shellQuoteValue, not hand-written escaping.

Note on verification: I tried to also reproduce this with a real CLI build against an actual O'Brien-style HOME directory, but hit a Git-Bash/MSYS path-quoting artifact in my own test harness (git itself failed to resolve the destination path), unrelated to this fix. Since the bug and fix are both pure string-matching logic, the unit tests exercise the exact reported scenario deterministically using the production shellQuoteValue/generateShellBlock functions, so I'm relying on those rather than fighting the harness further — happy to revisit if that's not sufficient.

[github-actions]

• [P1 blocking] Required compatibility test matrix is missing from the PR description. The repository requires real-CLI verification for Claude, Codex, CodeBuddy, and OpenCode across git, gitlab, and github. The test plan records only a local git repository and does not document the required agents or gitlab/github providers. Add the actual passing results before merge.

No additional code defects found in the reviewed diff.

[STiFLeR7]

On the compatibility-matrix request: I don't think it applies to this diff, and I'd rather explain why than pad the test plan with entries that don't add signal.

The full changeset (git diff --stat origin/main...fix/windows-shell-profile-detection) touches only:

• src/utils/shell-profile.ts (new)
• src/uninstall.ts, src/doctor-delivery.ts, src/resources/env.ts
• their tests, plus the two usage-guide docs

None of these reference src/providers/github, src/providers/tgit, GitLab, or any agent-specific hook code (hooks.ts, builtin-hooks.ts, or the per-tool injectors) — confirmed by grep, not just by inspection.

The reason is structural: the shell-profile env block is a single OS/shell-dependent mechanism (~/.zshrc / ~/.bashrc / ~/.bash_profile / etc.), injected identically regardless of which git host the team repo lives on and regardless of which AI tool is installed. git/gitlab/github only affect how the team repo itself is cloned/pushed — untouched here. Claude/Codex/CodeBuddy/OpenCode each have their own separate hook-injection code paths for their own config files — also untouched here; this PR doesn't add or change anything in that surface.

My existing real-CLI verification already exercises the one provider capability this PR's code path actually uses (git clone/pull against a local git remote), run generically — nothing in the fix branches on provider type. Running the same shell-profile logic again under CodeBuddy/OpenCode or against a GitLab/GitHub-hosted repo would just re-confirm code this PR does not modify.

Happy to add specific matrix entries if a maintainer sees an interaction I'm missing — but I'd want to know what that interaction is rather than filling in results for combinations this change can't affect.

[CarlosWonMore]

Windows 11 real-machine validation of this PR (built from a983ef0)

Environment: Windows 11 25H2, Node 22.22.2, Git for Windows (/usr/bin/bash). We reported #661/#672, filed #686 and #682, and supplied the Windows E2E records on #680/#687 — this is our daily platform.

We downloaded the tree at a983ef0, ran npm ci --ignore-scripts (the opencode-ai postinstall cannot fetch a Windows binary here and it is test-only) plus npm run build, then drove the built dist/index.js against a scratch $HOME and a local team repo.

1. The fix works, end to end

Fixture: ~/.profile exists (it only sources ~/.local/bin/env), no ~/.bash_profile / ~/.bash_login, and ~/.bashrc carries a pre-#680 teamai block (raw backslashes, unquoted — the #661 form):

[ -f D:\...\.teamai\env.sh ] && source D:\...\.teamai\env.sh

step	result
before pull — bash -lc	E2E_TOKEN = <unset>
teamai pull --force	Synced 1 env variable(s) → block written to ~/.profile
after — bash -lc	E2E_TOKEN = e2e-secret-value
teamai doctor	✔ Env variables injected in shell profile

detectShellProfile() resolves to .profile on Windows exactly as intended, and the block now reaches the login shell that teamai's own hook commands run under. Confirmed on hardware, not by reading.

2. Finding — envBlockSourcesPath() matches one spelling only, and that hides the legacy block

posixPath is envShPath.split(path.sep).join('/'), i.e. D:/…/.teamai/env.sh, and the function requires either shellQuoteValue(posixPath) or that substring. A block written by a pre-#680 CLI carries backslashes, so neither matches — even though it names the same env.sh of the same scope. Two observable consequences in the run above:

• doctor stays green while a dead block remains. After pull --force wrote .profile, .bashrc still held the unusable backslash block and doctor reported no problem — it only inspects the file detectShellProfile() resolves to.
• uninstall does not clean it. teamai uninstall --force printed ✔ Cleaned shell profile: …\.profile and left the .bashrc block exactly as it was. So the upgrade path named in the PR description — "a stale block in .bashrc … uninstall now removes both" — holds only when the stale block happens to be in the drive form. For anyone upgrading from a pre-fix(env): make the shell-profile block load on Windows #680 build it does not, which is the common case now that fix(env): make the shell-profile block load on Windows #680 landed yesterday.

A milder variant of the same shape, seen on our own machine: the block there is functional but spelled in the MSYS drive form /c/… (written by a locally patched 0.24.0, not by a release). envBlockSourcesPath rejects it, and doctor prints "a POSIX shell reads an unquoted backslash as an escape" — a reason that is simply not true of a correctly quoted, working block.

Suggestion: make the comparison spelling-insensitive — normalize both sides first (drive letter ⇄ /c/, \ ⇄ /, quoted or not) instead of looking for one exact string. SHELL_PROFILE_CANDIDATE_NAMES already gives you the file set; the same normalization applied to the source target would let both doctor and uninstall see the legacy block.

3. Finding — the injection side has no counterpart to the new multi-file cleanup

buildRemovalPlan now scans every candidate profile, but injectShellProfile() still writes only the single file detectShellProfile() resolves to:

private async injectShellProfile(profilePath: string, block: string) { … }

On this fixture pull --force therefore produced two teamai blocks — live in .profile, dead in .bashrc — and nothing migrates or removes the old one. Combined with (2) that is permanent: doctor does not look there, and uninstall does not recognise it. Even where the legacy block is recognised (drive form), the state is ambiguous, because that block's source may point at another scope's env.sh and inject wrong values into whatever shell reads that file. Since the scope check you added already makes the match precise, migrating (write the resolved profile, drop this scope's block from the legacy file) — or at minimum having doctor name the command that performs the migration — would close it.

4. Two smaller notes

• ~/.profile existing is the reason Git for Windows' /etc/profile.d/bash_profile.sh does not synthesize the ~/.bash_profile that would have sourced .bashrc; its guard is [ -e ~/.bashrc ] && ! -e ~/.bash_profile && ! -e ~/.bash_login && ! -e ~/.profile. Worth a sentence in the PR body, because it makes the bug look environment-specific when it is not. A fresh-$HOME matrix on this box confirms the order you implement: .bashrc only → Git for Windows creates a sourcing .bash_profile → loads; .bashrc + .profile → .profile is read and .bashrc never is; .bashrc + .bash_login → .bash_login.
• Unrelated to this change, but seen in the same build: teamai pull prints Skipping hook injection for codebuddy, workbuddy: no shell is available in this environment. That is the /bin/sh gate (windows codebuddy跳过hook #579/fix(hooks): run CodeBuddy's Windows hooks through cmd.exe #637), untouched here.

5. On the compatibility-matrix finding, and on #684

We agree with your reply at 06:30. Nothing in this diff branches on the git provider or on per-tool hook code; re-running the same profile logic under CodeBuddy/OpenCode or against a GitLab-hosted repo would only re-confirm code this PR does not modify. We would rather see the two findings above addressed than the matrix padded.

On #684: it does not touch src/uninstall.ts at all, so the bot's P1 there stands, and it has neither the shared helper nor the injectable platform that makes the win32 branch genuinely assertable on the Linux/macOS runners. We would suggest landing this PR and either closing #684 or reducing it to the win32 test cases it can still contribute.

We can re-run the transcript above against any later commit and post it verbatim if that is useful.

[STiFLeR7]

@CarlosWonMore — thank you for the real hardware validation, this is exactly the kind of testing an emulated repro can't substitute for. Addressed both findings in aea31ef.

Finding 2 (legacy spellings invisible to doctor/uninstall): added envBlockReferencesDataHome, a looser "does this block belong to this scope" check covering the current format plus the two you reproduced — raw unquoted/unconverted backslashes (pre-#661) and the MSYS/Cygwin drive form (/d/Users/...). Kept it separate from envBlockSourcesPath, which stays strict and keeps answering "does this block actually load" for doctor's #661 check — conflating the two would make doctor stop reporting a genuine #661-style break just because a legacy spelling happens to match. uninstall.ts now uses the looser check for its candidate scan.

Finding 2's "doctor stays green" half, and Finding 3's "at minimum name the command" ask: doctor's env-delivery check now also scans the other candidate files for a stray same-scope block and reports it, naming teamai uninstall. Since this check runs automatically after every pull, I re-ran your exact fixture (.profile present sourcing something else, .bashrc carrying a pre-#661 raw-backslash block) end to end on a real build:

✔ Synced 1 env variable(s)
⚠ Pull finished, but 1 check(s) failed:
⚠   ✖ Env variables injected in shell profile
    → ...\.bashrc still carries a teamai env block for this scope from an
      earlier install; run `teamai uninstall` to remove it...

doctor reports the same, and uninstall --force then cleans both .profile and .bashrc, confirmed on disk after.

Finding 3 (migrate during pull itself): deliberately not doing this in this round. Teaching pull's write path to also delete files elsewhere is a bigger behavioral change than what's already in this PR, and I'd rather it get its own review than get folded in here under review pressure. doctor (and pull's own post-pull check, as above) now names the file and the fix, and uninstall performs it — I think that closes the visibility and cleanup gap without that larger change. Open to being told that's not enough.

Finding 4 (docs): updated both usage-guide docs with Git for Windows' exact guard condition ([ -e ~/.bashrc -a ! -e ~/.bash_profile -a ! -e ~/.bash_login -a ! -e ~/.profile ]) so the bug doesn't read as environment-specific.

Also added the unrelated MSYS drive-form case as its own unit test rather than only the pre-#661 raw form, since your report named both as things you'd actually seen.

Thanks also for weighing in on the compatibility-matrix thread and on #684 — appreciated.

[github-actions]

• [P1 blocking] Normalize the configured profile path before detecting strays — src/doctor-delivery.ts:597. With sharing.env.shellProfilePath: ~/.profile, readFileSafe() correctly expands ~, but profilePath remains literal while the candidate is absolute. The same physical file is therefore treated as a different profile, so doctor and post-pull checks always report its valid block as stale. Expand/normalize profilePath before reading and comparing.
• The PR description includes a detailed test plan and real-CLI end-to-end verification record; testing documentation is sufficient.

[STiFLeR7]

Addressed the P1 in cd739c4, plus a real CI failure the previous commit introduced.

The reported bug (doctor-delivery.ts:597): fixed. profilePath is now expanded via expandHome() up front, mirroring the pattern uninstall.ts already used for this same override — sharing.env.shellProfilePath: ~/.profile no longer gets compared as a literal ~/... string against always-absolute stray candidates. Re-verified with a real CLI build: pull and doctor both now correctly treat the resolved .profile as itself, not a stray copy.

Unplanned but important: CI (ubuntu/macos) failed on the previous push and caught something my own Windows-only local testing couldn't. candidateSpellings converted backslashes via envShPath.split(path.sep).join('/') — a no-op on a POSIX CI runner even for a Windows-shaped path, since path.sep there is /. Fixed by reusing isWindowsFormPath (the same shape-based check generateShellBlock already relies on for this exact reason), moved out of resources/env.ts into the shared utils/shell-profile.ts. Also caught and fixed a test of my own that fell into the mirror-image version of the same trap (fabricated a Windows-style block by string-replacing / for \ in a POSIX-on-CI path, producing something with no drive letter that can't occur on disk).

CI is green again on this push; will keep an eye on it.

[github-actions]

• [P1 blocking] src/doctor-delivery.ts:595 treats any same-scope block in another candidate profile as a failed delivery. After upgrading, a valid block may exist in the newly selected .bash_profile while the previous .bashrc block remains; environment delivery works, yet every pull/doctor reports failure until the user manually edits files or performs a destructive full uninstall. Stale duplicate cleanup should not make the delivery health check fail, or pull should migrate it automatically.
• [P1 blocking] The PR description’s E2E record only covers a local git repository and does not document the required Agent matrix (Claude, Codex, CodeBuddy, OpenCode) or Provider matrix (git, gitlab, github). Add the mandated real-CLI verification results before merge.
• [P2 non-blocking] src/utils/shell-profile.ts:135 adds substantial speculative ownership logic for raw paths and “locally-built or hand-patched” MSYS spellings, expanding a focused profile-selection fix into destructive cross-file cleanup. This conflicts with the repository’s surgical-change/Occam’s-razor rule; keep the PR scoped to shared profile detection unless these legacy formats are demonstrated production states.

[STiFLeR7]

Addressed the P1 in 5f762ac.

Severity finding (doctor-delivery.ts:595): fixed by splitting the check. buildEnvDeliveryCheck now returns two independent Checks: Env variables injected in shell profile (unchanged delivery-correctness semantics — missing/stale vars, block doesn't load) and a new No stale env blocks left behind that only fails when a legacy/duplicate block for this scope sits elsewhere. Re-ran the exact upgrade scenario on a real build:

  ✔ Env variables injected in shell profile
  ✖ No stale env blocks left behind
    → ...\.bashrc still carries a teamai env block for this scope from an
      earlier install; run `teamai uninstall` to remove it...

A working delivery now reports healthy; the leftover is still surfaced, just not as the same failure. I went with "split into two checks" over "auto-migrate during pull" for the same reason I gave earlier in this thread — the latter is a bigger behavioral change I'd rather not fold in under review pressure.

Compatibility matrix (repeated): this was already addressed in my reply at 06:30:41, and @CarlosWonMore independently agreed at 08:19:27 ("Nothing in this diff branches on the git provider or on per-tool hook code... We would rather see the two findings above addressed than the matrix padded"). Standing on that — happy to revisit if a specific interaction is named.

P2: legacy-format matching is speculative scope creep: these aren't speculative. @CarlosWonMore reported both formats from real hardware in this same thread — the raw/unquoted pre-#661 form ("we reported #661/#672, filed #686 and #682... this is our daily platform") and the MSYS drive form ("seen on our own machine: the block there is functional but spelled in the MSYS drive form /c/…, written by a locally patched 0.24.0"). Removing that handling would reopen the exact gap their hardware testing found. I'd rather keep it scoped to what's demonstrated than trim it back to a form that's already known to miss real installs.

[CarlosWonMore]

Windows 11 real-machine re-verification: aea31ef → cd739c4

My earlier comment reported two findings from hardware testing of a983ef0. This is the re-verification of your fixes, on the same machine and the same fixture: Windows 11 25H2, Node 22.22.2, Git for Windows (/usr/bin/bash).

Both commits were built from source (npm ci --ignore-scripts + npm run build) and the built dist/index.js was driven against a scratch $HOME plus a local git team repo. I ran both commits through the identical three-scenario matrix so the delta is isolated rather than asserted:

• aea31efea — your fix for the two findings I reported
• cd739c471 — that plus the ~-normalization fix for the bot's P1

Results

#	check	aea31ef	cd739c4
1	legacy in-scope block (raw, unquoted, unconverted backslashes) left in .bashrc — does pull/doctor flag it?	✅ flagged; names only .bashrc; names teamai uninstall	✅ same
2	does uninstall --force clean both .profile and .bashrc?	✅ both cleaned, 0 blocks left	✅ same
3	same block in the MSYS drive form (/d/Users/...)	✅ flagged and cleaned	✅ same
4	sharing.env.shellProfilePath: ~/.profile	❌ false positive — reported .bashrc, .profile	✅ only .bashrc

Row 3 is the shape our own machine actually carries. Our ~/.bashrc holds

[ -f "/c/Users/Carlos/.teamai/env.sh" ] && source "/c/Users/Carlos/.teamai/env.sh"

written by a locally-patched build. Before this PR both doctor and uninstall were blind to it — uninstall printed only Cleaned shell profile: …\.profile and the .bashrc block survived permanently. It is now found, flagged, and removed. That closes both findings I reported; thank you for turning them around.

Row 4 is the bot's P1 reproduced. With shellProfilePath: ~/.profile and .profile present, aea31ef flagged its own target file as a stray leftover:

✖ Env variables injected in shell profile
  → …\tilde\.bashrc, …\tilde\.profile still carries a teamai env block for
    this scope from an earlier install; run `teamai uninstall` to remove it…

cd739c4 reports only the genuine stray:

✖ Env variables injected in shell profile
  → …\tilde\.bashrc still carries a teamai env block for this scope from an
    earlier install; run `teamai uninstall` to remove it…

So expandHome() is confirmed on hardware, not merely by reading the diff. A label-normalized diff of the two full transcripts shows row 4 as the only behavioural difference — rows 1–3 are byte-identical, so nothing regressed in the paths I originally reported.

Also

• Your own new tests pass here too: vitest run src/__tests__/shell-profile.test.ts src/__tests__/uninstall.test.ts → 52/52 passed on Windows, including the three envBlockReferencesDataHome spellings and the pre-[bug] Windows: env 注入到 shell profile 时写的是原生路径，source 静默失败而 doctor 仍报通过 #661 uninstall case.
• Extracting isWindowsFormPath was the right call, and worth a note: the defect you hit in CI is not observable on Windows at all. On a Windows host envShPath.split(path.sep) and a shape-based check agree, so only a POSIX runner separates them. Windows-only testing would have shipped it green — good catch by CI, and the shape-based check is what makes the test meaningful on both hosts.

One incidental observation, not caused by this change

teamai uninstall left ~/.teamai/ and its contents on disk (config.yaml, debug.log, env.sh, state.json, .sync-lock) in 5 of 6 scenario runs. This reproduces on both commits, so it is pre-existing and unrelated to this PR — one run did print Removed …\.teamai/, so it looks intermittent rather than unconditional. Flagging it only so it is not mistaken for a regression from this change; I have not investigated it further.

[github-actions]

Findings

• [P1 blocking] src/doctor-delivery.ts:527 models stale blocks as a failed health check. Since this check also runs after pull, the exact upgrade scenario this PR targets—an old .bashrc block plus a new working .profile block—produces “Pull finished, but 1 check(s) failed” despite successful delivery. Its remediation also suggests teamai uninstall, which removes the entire installation. Stale-block cleanup should be informational or handled during migration, not fail post-pull health.
• [P2 non-blocking] src/doctor-delivery.ts:625 compares profile paths using raw string equality. On Windows, a valid override such as C:/Users/me/.profile differs textually from the generated candidate C:\Users\me\.profile, although both identify the same file. The valid current block is then incorrectly reported as stale. Normalize paths—and account for Windows case insensitivity—before comparing.

The PR description includes a detailed test plan and real-CLI end-to-end verification, so no testing-documentation finding is required.

[STiFLeR7]

Addressed both in c2ac325.

P1 (doctor-delivery.ts:527): agreed — splitting into two checks fixed the health-check semantics but not pull's own summary, which counted every failed check the same way. Added Check.informational?: boolean (doctor.ts); the new "No stale env blocks left behind" check sets it. pull.ts's post-pull summary now excludes informational failures from the Pull finished, but N check(s) failed count and prints them on their own line instead. doctor's exit code is untouched — a stray leftover is still worth flagging on its own.

Real-machine re-verification of the exact upgrade scenario (built dist/index.js, scratch $HOME, real local git team repo, shellProfilePath: .profile with a legacy block left in .bashrc):

- [user] Pulling team repo...
✔ [user] Team repo: 1 file(s) changed
✔ [user] Synced 1 env variable(s) to ...\.teamai/env.sh
  ✖ No stale env blocks left behind
    → ...\.bashrc still carries a teamai env block for this scope from an
      earlier install; run `teamai uninstall` to remove it, or delete the block manually.
  Run `teamai doctor` for the full report.

No "check(s) failed" banner; the leftover is still named.

P2 (doctor-delivery.ts:625): agreed, raw === was wrong. Added sameFile() in shell-profile.ts, resolved through path.win32/path.posix explicitly (not the ambient path) so the win32 case-insensitive branch is actually exercised on ubuntu/macos CI rather than only on a real Windows host — same reason platform is injectable elsewhere in this file.

Re-verified on the same real Windows box with shellProfilePath: "D:/.../home/.profile" (forward slashes) against the native D:\...\home\.profile candidate path.join builds: only the unrelated .bashrc leftover is flagged, .profile is not misreported as a stray copy of itself.

Added regression tests for both: pull-post-checks.test.ts (informational failures excluded from the count but still printed), shell-profile.test.ts (sameFile across separator/case, explicit platform arg so both branches run on CI), and doctor-env-delivery.test.ts (forward-slash shellProfilePath override). npx tsc --noEmit clean; full vitest run shows the same 30-file/70-test pre-existing Windows-host-only failure count as unmodified main (POSIX-path-literal test fixtures, disclosed earlier in this thread) — no new failures. Docs (both languages) updated to describe the informational-check behavior and the new stale-block check.

[github-actions]

• [P1 blocking] src/utils/shell-profile.ts:57 — Falling back to .bashrc is not stable. After the first pull, Git for Windows creates .bash_profile sourcing .bashrc; subsequent runs then select .bash_profile, inject a second block, and report the still-functional .bashrc block as stale. Create/use a stable login profile, or recognize the generated forwarding profile.
• [P1 blocking] src/doctor-delivery.ts:627 — sameFile() only compares normalized path strings, not filesystem identity. Common setups such as .bash_profile -> .bashrc cause the active profile to be reread through the symlink and falsely reported as stale, making doctor fail after a healthy pull. Resolve real paths or compare file identity before classifying candidates.

The PR description includes both a detailed test plan and real-CLI end-to-end verification, so no testing-documentation finding is needed.

[STiFLeR7]

Addressed in 02c93fe.

Confirmed the underlying mechanism first rather than assuming: checked /etc/profile.d/bash_profile.sh on a local Git for Windows install directly.

# add ~/.bash_profile if needed for executing ~/.bashrc
if [ -e ~/.bashrc -a ! -e ~/.bash_profile -a ! -e ~/.bash_login -a ! -e ~/.profile ]; then
  ...
  cat >~/.bash_profile <<-\EOF
	# generated by Git for Windows
	test -f ~/.profile && . ~/.profile
	test -f ~/.bashrc && . ~/.bashrc
	EOF
fi

So the P1 is real and exactly as described: a first pull with nothing on disk yet writes into .bashrc (correctly — nothing else exists), and that leaves precisely the condition above satisfied. The next Git Bash login shell auto-generates .bash_profile, and detectShellProfile's order then prefers it on the next pull — injecting a second block there and reporting the original, still-loading .bashrc block as stale.

One correction on the second finding's framing: .bash_profile here is a plain regular file containing a source ~/.bashrc line, not a symlink or hardlink — confirmed from the generated content above. fs.realpath() wouldn't touch it; there's no filesystem-level identity to resolve. The practical problem is real, the mechanism named for it isn't what's actually happening.

Fix: resolveActiveShellProfile() in shell-profile.ts — before running detectShellProfile's order-based fallback, check whether any candidate already carries a block for this scope's env.sh, and if so, stay there. Only a genuinely first pull (no existing block anywhere) falls through to the order. Both the write path (EnvHandler.pullItem) and the read path (doctor-delivery's envDeliveryProblems) now resolve through it, so they can't disagree on which file is "the" profile.

Real-machine verification of the exact sequence: pull #1 (nothing on disk) → .bashrc. Then dropped in the identical Git-for-Windows-generated .bash_profile content by hand (not through teamai, to isolate the scenario). Pull #2:

- [user] Pulling team repo...
✔ [user] Team repo: 1 file(s) changed
✔ [user] Synced 1 env variable(s) to ...\.teamai/env.sh

No duplicate block, no stale-block warning. .bashrc still holds the one block, .bash_profile is untouched. teamai doctor afterward:

✔ Env variables injected in shell profile
✔ No stale env blocks left behind

Added regression tests at three levels: resolveActiveShellProfile directly (including sticking to a lower-priority candidate to prove it overrides ordering, and not sticking to a different scope's block), EnvHandler.pullItem (two real pullItem calls with the forwarding file dropped in between), and updated the docs (both languages) to explain why the order-based preference only applies to a first pull.

npx tsc --noEmit clean; full vitest run unchanged at the same pre-existing 30-file/70-test Windows-host-only baseline (disclosed earlier in this thread) — 5 new tests added, all passing, no new failures.

[STiFLeR7]

FYI: Codex PR Review failed on 02c93fe, but it's a transient infra issue on the action's side, not a finding — the job's log shows its model stream disconnecting mid-review (stream disconnected before completion, 5 reconnect attempts, then codex exited with code 1) before it produced any output. No new findings were posted. I don't have admin rights on this repo to re-run the job myself (gh run rerun was refused). Every other check is green. Could someone with rights re-run that one job, or should I push a follow-up commit to get a fresh run?

[github-actions]

Findings

• [P1 blocking] 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. Shell changes, such as zsh to bash, have the same problem. Stickiness must only apply when the existing profile remains reachable by the active shell. src/utils/shell-profile.ts:227

Testing

• The PR description includes a detailed unit/type-check plan and real-CLI end-to-end records, so its testing documentation is sufficient. However, it misses the critical upgrade scenario above: .profile exists and .bashrc already contains the old TeamAI block.

[STiFLeR7]

Good catch — real, serious bug. Fixed in `1ed0141`.

`02c93fe`'s `resolveActiveShellProfile` scanned all of `SHELL_PROFILE_CANDIDATE_NAMES` in a fixed order and returned the first candidate carrying a matching block — broader than the Git-for-Windows-forwarding case it was written for. Since `.bashrc` sorts before `.profile` in that list, a stale pre-#682 block left in `.bashrc` would outrank a correctly order-picked, not-yet-written `.profile` — exactly the upgrade scenario reported, and exactly the original #682 bug, reintroduced silently: worse than before, since `doctor` no longer caught it (the stale block is well-formed where it sits, so `envBlockSourcesPath` on it reports true).

Fix: reworked to start from `detectShellProfile`'s order-based pick — the file the current environment actually reads — and only diverge from it when that pick's own content references another candidate by a home-relative path (`~/.bashrc`, `$HOME/.bashrc`), the shape a real sourcing line takes. A block sitting in a candidate the pick never reaches is no longer preferred over the pick, no matter what it contains.

Also worth flagging on myself: the first cut of that reference check was a bare substring match on the filename, and my own test's plain-English comment (`"...unrelated to .bashrc"`) satisfied it and failed the test — caught before push, tightened to require the actual `~/name` / `$HOME/name` shape.

Real-machine re-verification of both scenarios:

The reported upgrade case (stale `.bashrc` block, empty `.profile`, no forwarding between them):
```
✔ [user] Synced 1 env variable(s) to ....teamai/env.sh
✖ No stale env blocks left behind
→ ....bashrc still carries a teamai env block for this scope from an
earlier install; run `teamai uninstall` to remove it, or delete the block manually.
```
New block correctly lands in `.profile`; `doctor` reports `Env variables injected in shell profile: ✔`.

The prior round's Git-for-Windows forwarding case, re-run to confirm no regression:
```
✔ Env variables injected in shell profile
✔ No stale env blocks left behind
```
Still sticks to `.bashrc` through the generated `.bash_profile`, no duplicate.

Replaced the test that had asserted the old (incorrect) broad-stickiness behavior, and added the upgrade-case regression test. `npx tsc --noEmit` clean; full `vitest run` at the same pre-existing 30-file/70-test Windows-host-only baseline — no new failures.