Shell preference silently resets to system default after Homebrew upgrades the shell (canonicalized Cellar path breaks the match)

[thiagohflima]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

On macOS, when a shell installed via Homebrew (e.g. fish) is selected in Settings → Features → "Default shell for new sessions", the preference silently reverts to the system default login shell (zsh) every time brew upgrade updates the shell formula.

To reproduce

1. brew install fish and add /opt/homebrew/bin/fish to /etc/shells
2. In Warp, set the default shell for new sessions to Fish
3. Confirm that new sessions/tabs open fish
4. Run brew upgrade fish
5. Open a new Warp session → it starts zsh instead, and the setting has silently fallen back to the system default

Expected behavior

The shell preference survives a Homebrew upgrade of the shell. If the configured shell cannot be resolved, Warp should warn instead of silently falling back.

Screenshots, videos, and logs

No response

Operating system (OS)

macOS

Operating system and version

macOS Tahoe 26.6.2

Shell Version

fish 4.9.2 (Homebrew, /opt/homebrew/bin/fish)

Current Warp version

v0.2026.09.02.08.27.stable_01

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

Root cause analysis against the open-source codebase (master):

1. Warp canonicalizes shell paths during detection: resolve_all_executables and load_fallback_shells in app/src/terminal/available_shells.rs (lines 814-828 and 830-866) run dunce::canonicalize, resolving the stable Homebrew symlink /opt/homebrew/bin/fish to the versioned Cellar path /opt/homebrew/Cellar/fish/<version>/bin/fish.
2. That versioned path is what gets persisted: selecting the shell stores NewSessionShell::Executable(<canonicalized path>) via From<AvailableShell> for NewSessionShell (available_shells.rs:346-352) in set_user_preferred_shell (available_shells.rs:590-626).
3. On the next session start, matches_preference (available_shells.rs:207-222) compares the persisted path by exact string equality against the re-detected shells. After brew upgrade fish, Homebrew removes the old Cellar directory, and detection now canonicalizes to the new version's path → no match → get_user_preferred_shell hits .unwrap_or_default() (available_shells.rs:590-604) → SystemDefault → compute_fallback_shell() → the login shell (zsh). All of this is silent; the user just finds themselves in a different shell.

Fix direction:

• Primary: persist the pre-canonicalization (symlink) path discovered via PATH — e.g. /opt/homebrew/bin/fish, which is stable across Homebrew upgrades — and use the canonicalized path only as the dedupe key in resolve_all_executables / load_fallback_shells. Runtime validation (file_exists_and_is_executable) follows the live symlink, so launch keeps working across upgrades.
• Defense in depth: when the exact persisted path no longer exists, re-resolve the preference by shell file name / parse_shell_type_from_path among currently detected shells instead of falling back to the system default. This also heals preferences that were already persisted with a stale Cellar path.

Happy to open a PR with a regression test simulating a Homebrew layout (bin/fish -> Cellar/fish/<old>/bin/fish, then re-pointing the symlink to a new version).

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[warp-for-oss]

@thiagohflima

Here's what I found while triaging this issue:

This looks actionable from the provided reproduction. The current shell-selection logic appears to save a resolved Homebrew Cellar executable path, so a brew upgrade can make the saved selection stop matching and cause Warp to fall back to the login shell.

I've flagged this for the factory auto-implement queue.

Maintainer details

I concluded that homebrew-installed shells selected as the new-session default can stop matching after a formula upgrade because Warp persists and compares the canonicalized executable path instead of a stable symlink or recoverable shell identity..

Triage summary

This is an actionable macOS client bug in the shell selector / new-session shell preference path. The provided Homebrew fish reproduction is specific, and current code inspection supports the reported failure mode.

Evidence

• AvailableShells::new adds Homebrew search directories on macOS before loading known shells.
• resolve_all_executables and load_fallback_shells canonicalize discovered shell paths before constructing KnownLocal shell entries.
• From<AvailableShell> for NewSessionShell persists the KnownLocal executable path into new_session_shell_override.
• AvailableShell::matches_preference compares NewSessionShell::Executable values by exact path equality. If no detected shell matches, get_user_preferred_shell returns AvailableShell::default(), and shell startup falls back to the user/system default path.
• A Homebrew upgrade can repoint /opt/homebrew/bin/fish to a new /opt/homebrew/Cellar/fish/<version>/bin/fish target and remove the previous version, so an old persisted Cellar path no longer matches the newly detected shell.

Duplicate check

I enumerated 3,835 open non-PR issues and 22 recently closed non-PR issues. The closest matches were adjacent shell/path reports such as #13934, #3624, and #5444, but they involve SSH/Nix PATH bootstrap, hardcoded bash paths, or fish startup behavior rather than a Homebrew-upgrade reset of the saved new-session shell preference.

Suggested implementation direction

Persist a stable discovered shell path, such as the PATH or /etc/shells entry, while using the canonicalized path only for deduplication. Add a recovery path for stale saved executable preferences that can resolve the currently installed shell by shell type or command before falling back to the system default. A focused regression test can simulate a Homebrew bin/fish -> Cellar/fish/<version>/bin/fish symlink being repointed to a new version.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[thiagohflima]

Hi @oss-maintainers, could this be considered for ready-to-implement? PR #15837 is up implementing the triage suggestions, with regression tests included.