›_ Codex Issues
Codex Issues / #9989

Pass workspace directory to MCP servers

Open 💬 4 comments Opened Jan 27, 2026 by ginishuh
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

The Codex VS Code extension spawns MCP servers from the VS Code installation directory instead of the workspace directory. This fundamentally breaks semantic code analysis tools like Serena that rely on correct working directory to index and analyze codebases.

Impact

Serena provides symbolic code operations that are essential for large codebase work:

  • find_symbol / find_referencing_symbols - call graph traversal
  • replace_symbol_body - precise symbol-level edits
  • get_symbols_overview - fast structural understanding

Without correct cwd, these tools cannot auto-detect the project, forcing users to manually activate projects every session. This defeats the purpose of semantic tooling.

Current State

| Client | MCP Server cwd | Works? |
|--------|---------------|--------|
| Codex CLI | Project directory | ✅ |
| Codex VS Code (Remote: WSL) | /mnt/c/.../Microsoft VS Code | ❌ |

Proposed Fix

When spawning MCP servers, pass cwd: ${workspaceFolder} (or the active workspace root). This is a one-line fix that would unblock all path-dependent MCP tools.

Workarounds Attempted

  1. --project-from-cwd flag in Serena - fails because cwd is wrong
  2. Manual activate_project each session - works but error-prone
  3. Wrapper scripts - cannot access workspace info at spawn time
  4. CODEX_WORKSPACE_ROOT env var - only available at tool-call time, not spawn time

I've also filed a feature request on Serena to use CODEX_WORKSPACE_ROOT at tool-call time (oraios/serena#970), but the proper fix should be in the VS Code extension.

Related Issues

  • #7281 - WSL2 Remote spawns MCP with wrong cwd (my previous report)
  • #4222 - MCP servers not launched in workspace folder
  • #5387 - Related duplicate

Environment

  • Codex VS Code extension: v0.4.67
  • Platform: WSL2 Ubuntu on Windows 11
  • VS Code: Remote - WSL

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 7 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #8260
  • #7820
  • #8029

Powered by Codex Action

ginishuh · 7 months ago

Reviewed the potential duplicates - this is not a duplicate:

| Issue | Problem | This Issue |
|-------|---------|------------|
| #8260 | MCP servers fail to connect in Remote-SSH | MCP works, but spawns with wrong cwd |
| #7820 | MCPs in config.toml not visible to VS Code | MCPs are visible and functional |
| #8029 | Sandbox settings ignored | Unrelated (sandbox vs cwd) |

Key distinction: The other issues are about MCP connectivity/visibility. This issue is specifically about the working directory passed to MCP servers being the VS Code installation path instead of the workspace root.

The root cause may be shared (VS Code extension's MCP handling), but the symptom and fix are different. This requires explicitly passing cwd: ${workspaceFolder} when spawning MCP server processes.

Related but distinct from #7281 and #4222 which I also filed - those focus on the general problem, while this issue emphasizes the impact on semantic code tools like Serena.

drozzy · 6 months ago

The fact that codex doesn't pass the project dir is puzzling to me.

ub3dqy · 4 months ago

I can confirm this is broader than MCP server spawn and appears to affect the extension's working-directory normalization in general.

In my setup, the same Remote-WSL / Windows-workspace-path bug causes all lifecycle hooks to fail in the VS Code extension, even though the hook commands themselves use absolute paths.

Environment

  • IDE extension: 0.119.0-alpha.28 (embedded app-server)
  • Standalone CLI for comparison: codex-cli 0.120.0
  • IDE: VS Code with Remote-WSL
  • Host OS: Windows 11 Pro 22631
  • WSL: Ubuntu / WSL2
  • Workspace path on host: E:\Project\memory claude\memory claude (note Windows path + spaces)
  • codex_hooks = true

Symptom

Inside the VS Code extension, all hooks are shown as failed in the UI:

  • SessionStart
  • UserPromptSubmit
  • Stop
  • PostToolUse

Downstream capture/logging writes nothing during those sessions.

Evidence

Inspecting ~/.codex/logs_2.sqlite, the cwd recorded in turn spans is malformed:

/mnt/c/Users/<user>/AppData/Local/Programs/Microsoft VS Code/e:\Project\memory claude\memory claude

That path is neither the VS Code install directory nor the WSL workspace root. It looks like the extension/app-server is combining the VS Code install dir with the raw Windows workspace path instead of normalizing E:\... to /mnt/e/... first.

Why this matters

This is not only an MCP-server spawn problem. Once the extension hands child processes an invalid cwd, other path-dependent subprocesses also break. In my case that meant hook commands consistently reported failed in the extension, while the same hook stack worked fine outside the extension.

Confirmed workaround

Run standalone codex directly from a WSL terminal in the project root:

cd /mnt/e/Project/memory\ claude/memory\ claude
codex

In that mode:

  • cwd is clean: /mnt/e/Project/memory claude/memory claude
  • hook events show completed
  • the same logging/capture pipeline works normally

So this still looks like a VS Code extension Remote-WSL cwd-normalization bug, but the impact is broader than MCP tooling: it can break extension-managed hooks and other child-process workflows too.