Skip to content

fix(terminal): ignore stale env.cwd from a different session's cd - #62408

Merged
ethernet8023 merged 1 commit into
mainfrom
fix/terminal-stale-cwd-cross-session
Jul 14, 2026
Merged

fix(terminal): ignore stale env.cwd from a different session's cd#62408
ethernet8023 merged 1 commit into
mainfrom
fix/terminal-stale-cwd-cross-session

Conversation

@ethernet8023

@ethernet8023 ethernet8023 commented Jul 11, 2026

Copy link
Copy Markdown
Collaborator

What does this PR do?

The terminal environment is shared process-globally (collapsed to the "default" key), so env.cwd tracks the LAST session that ran a command. _resolve_command_cwd() trusted env.cwd unconditionally — no ownership check — so when session A's cd left env.cwd pointing at A's checkout, session B's first terminal command inherited A's stale cwd and ran in the wrong workspace.

The file tools already solved this exact shared-env problem with _live_cwd_if_owned() checking env.cwd_owner (tools/file_tools.py:272). The terminal tool never got the same guard.

Fix: capture env.cwd_owner BEFORE the current session claims it, and pass it as prev_owner to _resolve_command_cwd. When the previous owner was a different session, env.cwd is stale — fall through to default_cwd (the config/override cwd for this session) instead. Once the session has claimed the env, subsequent calls in the same session still trust env.cwd so in-session cd state survives.

Related Issue

Fixes new sessions in the desktop app frequently being in the wrong pwd :D

Type of Change

  • 🐛 Bug fix (non-breaking change that fixes an issue)

Changes Made

  • tools/terminal_tool.py_resolve_command_cwd(): added prev_owner param; when the env's previous owner was a different session, env.cwd is stale and falls through to default_cwd
  • tools/terminal_tool.py — call site (line ~2373): capture prev_cwd_owner = getattr(env, "cwd_owner", "") before claiming the env
  • tools/terminal_tool.py — both _resolve_command_cwd call sites (background + foreground): pass prev_owner=prev_cwd_owner
  • tests/tools/test_terminal_task_cwd.py — two new regression tests

How to Test

  1. scripts/run_tests.sh tests/tools/test_terminal_task_cwd.py -v — 12 tests pass (10 existing + 2 new)
  2. scripts/run_tests.sh tests/tools/test_terminal_tool.py tests/tools/test_terminal_task_cwd.py tests/tools/test_terminal_config_env_sync.py tests/tools/test_terminal_compound_background.py tests/tools/test_terminal_exit_semantics.py -v — 114 tests pass, no regressions
  3. scripts/run_tests.sh tests/tools/test_file_tools.py -v — 52 tests pass (file_tools share the cwd_owner concept)

New tests:

  • test_stale_env_cwd_from_different_session_is_ignored — env owned by session-A, session-B calls terminal → command runs with config cwd, not session-A's stale env.cwd
  • test_same_session_env_cwd_is_trusted_after_first_claim — env owned by same session → env.cwd is trusted (in-session cd survives)

Checklist

Code

  • I've read the Contributing Guide
  • My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
  • I searched for existing PRs to make sure this isn't a duplicate
  • My PR contains only changes related to this fix/feature (no unrelated commits)
  • I've run pytest tests/ -q and all tests pass
  • I've added tests for my changes (required for bug fixes, strongly encouraged for features)
  • I've tested on my platform: Linux (NixOS)

Documentation & Housekeeping

  • N/A — no config keys, no architecture changes, no tool schema changes

The terminal environment is shared process-globally (collapsed to the
default key), so env.cwd tracks the LAST session that ran a command.
_resolve_command_cwd() trusted env.cwd unconditionally — no ownership
check — so when session A left env.cwd pointing at A's checkout,
session B's first terminal command inherited A's stale cwd and ran in
the wrong workspace.

The file tools already solved this exact shared-env problem with
_live_cwd_if_owned() checking env.cwd_owner. The terminal tool never
got the same guard.

Fix: capture env.cwd_owner BEFORE the current session claims it, and
pass it as prev_owner to _resolve_command_cwd. When the previous owner
was a different session, env.cwd is stale — fall through to default_cwd
(the config/override cwd for this session) instead. Once the session
has claimed the env, subsequent calls in the same session still trust
env.cwd so in-session  state survives.
@ethernet8023
ethernet8023 force-pushed the fix/terminal-stale-cwd-cross-session branch from f776c1c to 6a1f40e Compare July 11, 2026 02:15
@alt-glitch alt-glitch added type/bug Something isn't working comp/tools Tool registry, model_tools, toolsets tool/terminal Terminal execution and process management P2 Medium — degraded but workaround exists labels Jul 11, 2026
@ethernet8023
ethernet8023 merged commit 7e84d2b into main Jul 14, 2026
31 checks passed
@ethernet8023
ethernet8023 deleted the fix/terminal-stale-cwd-cross-session branch July 14, 2026 19:31
@teknium1 teknium1 added the area/sessions Session lifecycle, resume, persistence, history label Jul 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area/sessions Session lifecycle, resume, persistence, history comp/tools Tool registry, model_tools, toolsets P2 Medium — degraded but workaround exists tool/terminal Terminal execution and process management type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants