Subsequent commands run in wrong directory if llm uses `cd <dir>`

[chris-garrett]

App Version

3.22.6 (ed536a9)

API Provider

Anthropic

Model Used

claude-sonnet-4-20250514

Roo Code Task Links (Optional)

No response

🔁 Steps to Reproduce

In the first execute_command the llm changes directories to triplit/client and now any subsequent commands are in the wrong location.

I'm stripping out a lot here but this is the gist from the task history:

---

Assistant:

<execute_command>
cd triplit/client && npm install react-oauth2-pkce
</execute_command>

---

Assistant:

I notice the package is deprecated. Let me check for a better alternative OAuth PKCE library. Let me search for a more current OAuth PKCE library:

<execute_command>
cd triplit/client && npm search oauth2 pkce
</execute_command>

---

Assistant:

Let me fix the path and search for alternatives:

<execute_command>
cd triplit/client && npm search oauth2-pkce
</execute_command>

---

Assistant:

I need to use the correct path. Let me check the current directory and navigate properly:

<execute_command>
pwd && ls -la
</execute_command>

💥 Outcome Summary

I expect when run tool executes it uses the project root (or consistent one) every time.

📄 Relevant Logs or Errors (Optional)

[dosubot]

Hi @chris-garrett! I'm Dosu and I’m helping the Roo-Code team.

This happens because Roo Code reuses terminal sessions for efficiency, so when a command like cd <dir> runs, the working directory change persists for all subsequent commands in that terminal. There isn't a documented setting to force every command to start from the project root or a consistent directory—terminal state (including the working directory) is preserved by design for context and performance reasons [docs].

To work around this, always prefix commands with the desired directory (e.g., cd <project_root> && ...) or manually reset the terminal if you need to ensure a specific starting point. If this workflow is critical, you may want to monitor for future updates or provide feedback to the team, as this is a known limitation in the current design.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}   

[roomote]

PR #5425 has been created to address this issue: #5425

The fix enhances the terminal registry to properly track working directory changes and ensures subsequent commands run in the correct directory even after cd operations.

[xtr3me]

@roomote it would be great if we can stripping out changing directories if it is not needed. Because if the LLM uses the cd command to go to the current root directory (while already being there). The command itself is not automatically approved by the whitelist anymore.

For example:
Command auto execute whitelist:

bundle install
npm install

Current working directory in the terminal:
/users/pieter/coding_project

llm wants to execute this command:
cd /users/pieter/coding_project && bundle install

It doesn't get executed automatically as cd <directory> && bundle install is not approved, but bundle install is.

[roomote]

@xtr3me You raise an excellent point about the auto-execute whitelist being broken by unnecessary directory changes. This is indeed a significant UX issue.

The problem you've identified has two main aspects:

1. Persistent working directory: When the LLM uses cd <dir> && command, subsequent commands continue to run from that changed directory instead of resetting to the project root
2. Whitelist bypass: Commands that should auto-execute (like bundle install, npm install) require manual approval when prefixed with cd

Potential Solutions

1. Smart Directory Change Detection

We could implement logic to detect when a cd command is redundant:

• If the target directory is the same as the current working directory, strip the cd portion
• If the command is already whitelisted without the cd prefix, execute just the core command

2. Working Directory Reset

Each execute_command could start from a consistent base directory (project root) rather than inheriting the previous command's working directory.

3. Enhanced Whitelist Patterns

Extend the whitelist to include common patterns like:

• cd <any-path> && <whitelisted-command>
• Use regex patterns to match these combinations

Questions for Implementation

1. Would you prefer that each command starts from the project root by default?
2. Should we maintain a list of "safe" directory change + command combinations?
3. Are there specific commands beyond bundle install and npm install that are commonly affected?

This seems like a high-priority UX improvement since it directly impacts the seamless execution flow that users expect. Would you like me to explore implementing one of these solutions?