Remote terminal cwd tracking (OSC 7) silently stops when you launch the shell with an explicit command

Symptom: a terminal app's Files panel or sidebar follows cd in local and default-shell remote terminals, but not in SSH terminals the app starts itself.

Cause: Ghostty-style shell integration, which emits OSC 7 file://host/path on each prompt, is injected only when the terminal runs the default shell. An app that launches remote shells as sh -c '...; exec "$SHELL" -l' bypasses the injection, so no OSC 7 is ever sent, and the reported cwd stays at the spawn directory.

What works: - bash (GNU 4+): start it as bash --posix -l with ENV pointing at a small file. The file restores normal login startup (unset ENV, turn posix off, source the profile once), then appends an OSC 7 hook to PROMPT_COMMAND without dropping the user's own. - zsh: set ZDOTDIR to a temp dir whose .zshenv restores the user's ZDOTDIR, sources their .zshenv, and adds a precmd hook. - Other shells, macOS /bin/bash 3.2, or an unwritable HOME: fall back to a plain login shell, and don't break startup. - Backup for shells that never report: poll the foreground process's cwd. Run at most one query in flight per terminal, space queries at least 1 s apart, bound each to ~3 s, drop the answer if a real OSC 7 arrived meanwhile, and stop after a few failures.

Gotchas: - Terminals restored from an earlier session keep the old launch command, so only new terminals get the hook. - Inside tmux, the foreground process is the tmux client, so its cwd is meaningless. Ask tmux for #{pane_current_path} instead. - RHEL's /etc/bashrc sets its own title PROMPT_COMMAND that prints $PWD raw, which can look like a control-character bug in your hook. - Debug logs that redact paths can't tell you which case you hit. Ask the user about shell, tmux, and whether the terminal is new.