Problem
rename_tmux_window() is called in prepare_project() (core.py:407) before the sandbox is assembled or the shell is exec'd. If anything downstream fails — bwrap rejects an arg, the shell path is invalid, vault mount fails, etc. — the tmux window has already been renamed to the project's display name, even though the user never actually entered that environment.
The result is a misleading window title: the user is dropped back to their original shell, but the tab still says they're "inside" the project.
Repro
- Have a project config that would cause bwrap to error (e.g. the duplicate-docker-socket case fixed in 202604.4.1a0, or any bad blacklist path).
- Run
pwrap <project> from inside tmux.
- pwrap exits non-zero, but the current tmux window is now named
<project>.
Suggested fix
Either:
- Rename only after all setup succeeds and immediately before
os.execvp (so any pre-exec failure leaves the title alone), or
- Capture the original window name before renaming and restore it on any non-exec exit path.
The first option is simpler and good enough for the common case.
Problem
rename_tmux_window()is called inprepare_project()(core.py:407) before the sandbox is assembled or the shell is exec'd. If anything downstream fails — bwrap rejects an arg, the shell path is invalid, vault mount fails, etc. — the tmux window has already been renamed to the project's display name, even though the user never actually entered that environment.The result is a misleading window title: the user is dropped back to their original shell, but the tab still says they're "inside" the project.
Repro
pwrap <project>from inside tmux.<project>.Suggested fix
Either:
os.execvp(so any pre-exec failure leaves the title alone), orThe first option is simpler and good enough for the common case.