Is your feature request related to a problem?
The current implementation of _update_working_directory_from_claude_response uses Regex patterns to monitor directory changes (e.g., cd commands) in Claude's output. While it validates if the new path is within the approved_directory, this mechanism is reactive rather than preventative.

If Claude CLI executes a command that moves it outside the approved_directory, the bot's internal state tracking (user_data["current_directory"]) will correctly refuse to update. However, the underlying Claude CLI process remains in that "forbidden" directory for subsequent commands in the same session. This could allow access to sensitive system files if the LLM decides to explore beyond the project scope.

Describe the solution you'd like
I'd like to propose a more robust enforcement mechanism at the claude_integration level:

1. Command Pre-validation: Explicitly prepend directory enforcement or verify the CWD before each command execution.
2. Strict Session Reset: If a directory change is detected that violates the approved_directory constraint, the session should be forced back to the approved root or terminated.
3. CLI Wrapper Hardening: Ensure that the claude CLI execution is always scoped strictly to the project path, perhaps using environment-level constraints if supported by the CLI.

Describe alternatives you've considered
Currently, the bot relies on sandbox_enabled settings, but as noted in CONTRIBUTING.md, some commands run outside the sandbox. Strengthening the path validation logic in the bot handlers is a necessary layer of "Defense in Depth" (though I prefer calling it "Logic Robustness").

Additional context
As the project moves towards TODO-7 (File uploads and Git integration), ensuring that the working directory is strictly enforced becomes critical to prevent accidental or malicious system-wide modifications. I'd love to hear the maintainers' thoughts on the best architectural approach to fix this state mismatch between the Bot's tracker and the CLI's actual state.