Shell tool fails with "The directory name is invalid" (os error 267) on Windows when workspace_dir doesn't match action_dir

[Harryjsmith40]

Summary

On a Windows machine, every shell/command execution fails with Failed to execute command: The directory name is invalid. (os error 267) — even trivial commands like echo hello or pwd. The shell tool cannot initialise because the configured working directory is invalid at the OS level.

Problem

What happened: Every shell tool call (shell, node_exec, npm_exec) fails with the same error. Commands like echo hello, pwd, dir, ls all fail identically. The error is os error 267 which maps to Windows ERROR_DIRECTORY — the directory name is invalid.

What was expected: The shell tool should either (a) fall back to a valid directory, (b) surface a clear error about which path is invalid and why, or (c) auto-create the missing directory.

Impact: The agent is completely unable to execute any shell commands, read files, run scripts, or interact with the filesystem. This blocks all code-repo work, file operations, and general tool usage on Windows.

Version / Platform:

• Platform: Windows 11 - 25H2 (OS Build 26200.8457)
• OpenHuman version: v0.57.13

Solution (suspected)

The root cause is likely a mismatch between workspace_dir and action_dir:

1. workspace_dir defaults to ~/.openhuman/users/<id>/workspace — this path is auto-created at startup and is valid.
2. action_dir defaults to ~/OpenHuman/projects — this path is the shell tool's CWD. If it doesn't exist (e.g. the user never created it, or the tilde expansion produces a malformed Windows path like C:\Users\Harry/OpenHuman/projects with mixed separators), cmd.current_dir() will fail with ERROR_DIRECTORY.
3. The shell tool does NOT check if action_dir exists before setting it as CWD — it just passes it to cmd.current_dir() and lets the OS error bubble up as a generic "Failed to execute command" message.
4. The error message is opaque — it doesn't tell the user WHICH directory is invalid or why.

Related: Issue #2379 (closed) fixed a similar "program not found" problem on Windows by adding Windows env vars to the allowlist. This is a different failure mode (invalid directory path vs missing executable).

Acceptance criteria

• Repro gone — Shell commands no longer fail with ERROR_DIRECTORY on Windows when action_dir doesn't exist
• Clear error messaging — If action_dir is invalid, the error message tells the user which path is the problem and suggests a fix (e.g. "The configured action_dir 'X' does not exist. Set a valid path in Settings → Agent → Working Directory or create the directory.")
• Auto-creation or fallback — Either auto-create action_dir at startup (like workspace_dir is), or fall back to a valid temp directory with a warning
• Diff coverage ≥ 80%

Related

• Issue Windows 11 bug #2379 — Windows "program not found" (env allowlist fix, closed)
• Issue Make action_dir editable in Settings UI (currently env/TOML only) #3240 — Make action_dir editable in Settings UI (closed, PR feat(settings): make action_dir editable in Agent OS access (#3240) #3305)
• Issue Failed to initialize memory_tree schema: disk I/O error: Error code 1546: Error attempting to truncate file #2410 — Failed to initialize memory_tree schema: disk I/O error (workspace path issue)
• CLAUDE.md documents the workspace_dir / action_dir split but the shell tool's error handling doesn't account for a missing action_dir

[Harryjsmith40]

After investigating locally, I can confirm the tilde-expansion theory. On Windows, ~ resolves to C:\Users\Harry, but if the code joins it with a forward-slash path like ~/OpenHuman/projects, you get mixed separators: C:\Users\Harry/OpenHuman/projects. The Windows API SetCurrentDirectoryW rejects this with ERROR_DIRECTORY (267).

Suggested fix locations to look at:

• Wherever cmd.current_dir() is called in the shell tool (likely crates/agent/src/shell.rs or similar)
• The config parsing that sets action_dir — validate the path exists at load time and either create it or fall back

Related: since #3240 made action_dir editable in Settings UI, the simplest fix might be validating the path on save and showing an inline error if it doesn't exist, rather than letting the shell tool fail silently.