Greptile Summary

This PR fixes StandaloneTerminalManager (used in Background Exec mode) ignoring the user-configured "Default Terminal Profile" and always spawning the system default shell. The fix mirrors VscodeTerminalManager: profile id → shell path resolution is applied both when creating terminals and when matching/reusing them.

• getOrCreateTerminal(): computes expectedShellPath once per call and filters both the CWD-match and the fallback-reuse candidates against it, then passes it to registry.createTerminal() so TerminalInfo.shellPath is set correctly.
• setDefaultTerminalProfile(): resolves the incoming profile id to a shell path before forwarding to handleTerminalProfileChange(), so idle terminals running the old shell are properly closed on profile switch.
• Tests: three new cases cover bash/zsh (posix) or powershell-legacy/cmd (Windows) — correct shell on create, undefined for the default profile, and no terminal reuse across profile switches.

Confidence Score: 5/5

Safe to merge — the change is narrowly scoped to StandaloneTerminalManager and correctly mirrors the already-working VscodeTerminalManager behavior.

The logic is straightforward: profile id resolution is added in exactly two places (terminal creation and profile-change cleanup), the default-profile path (shellPath = undefined) is preserved unchanged, and the new tests validate all three behavioural cases across both posix and Windows platforms. No regressions were found in terminal reuse, background-command tracking, or the handleTerminalProfileChange cleanup path.

No files require special attention.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["getOrCreateTerminal(cwd)"] --> B["Resolve expectedShellPath\n(profile !== 'default'\n  ? getShellForProfile(profile)\n  : undefined)"]
    B --> C{"Find terminal\n!busy &&\nshellPath === expected &&\n_cwd === cwd?"}
    C -- match --> D["Return existing terminal"]
    C -- no match --> E{"terminalReuseEnabled?"}
    E -- yes --> F{"Find terminal\n!busy &&\nshellPath === expected?"}
    F -- match --> G["cd to cwd\nReturn reused terminal"]
    F -- no match --> H["Create new terminal\nwith shellPath = expected"]
    E -- no --> H
    H --> I["registry.createTerminal\n({ cwd, name, shellPath })"]
    I --> J["TerminalInfo.shellPath set\n→ StandaloneTerminalProcess.run\n  uses shellPath"]

    K["setDefaultTerminalProfile(profile)"] --> L["previousProfile !== profile?"]
    L -- yes --> M["newShellPath =\nprofile !== 'default'\n  ? getShellForProfile(profile)\n  : undefined"]
    M --> N["handleTerminalProfileChange(newShellPath)\nclose idle terminals where\nshellPath !== newShellPath"]
    L -- no --> O["return {closedCount:0, busyTerminals:[]}"]

_{Reviews (3): Last reviewed commit: "test(terminal): use built-in Windows Pow..." | Re-trigger Greptile}

Pushed a follow-up (a0eaca0):

• Review feedback: dropped the redundant (terminal as any)._shellPath assertion — terminalInfo.shellPath already carries the same value (the registry sets both from options.shellPath), so the private-field check added no coverage and was brittle to a rename. Thanks @greptile-apps.
• CI (windows-latest) fix: the reuse test assumed bash/zsh resolve to distinct shells, but getAvailableTerminalProfiles() only exposes those on macOS/Linux — on Windows both fell back to the same default shell, so the terminal was correctly reused and the assertion failed. The tests now pick a platform-appropriate profile pair (powershell-7/cmd on Windows, bash/zsh elsewhere) and guard the distinctness assertion.

Both changes look good. The test file is clean and the fixes are well-reasoned:

1. Dropped _shellPath assertion — correct call. terminalInfo.shellPath is the stable public surface; the private field was just noise.

2. Windows CI fix — the platform-appropriate profile pair plus the distinctness guard (if (getShellForProfile(PROFILE_A) === getShellForProfile(PROFILE_B)) { return }) handles the edge case cleanly without skipping the test entirely on any platform.

One minor note: powershell-7 assumes PowerShell 7 is installed on the Windows CI runner. If it's not available, getShellForProfile("powershell-7") would likely return undefined, making it the same as cmd's fallback, which would trigger the guard and skip the assertion silently. That's safe behavior — just worth verifying the CI image has PS7. If it doesn't, ["powershell", "cmd"] (the built-in Windows PowerShell) might be a more reliable choice.

Otherwise this is solid — nice work addressing both points.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.

Good catch on the PS7 assumption — switched the Windows pair to powershell-legacy (built-in Windows PowerShell 5.x, present on every Windows install) in f1da853.

For the record: getAvailableTerminalProfiles() pushes the profile entries with hardcoded constant paths and does no fs.existsSync check, so getShellForProfile("powershell-7") would actually have returned the constant PS7 path (not undefined) even if PS7 weren't installed — meaning the guard wouldn't have silently skipped. But powershell-legacy is the more robust/clear choice regardless.