Skip to content

Pass workspace directory to MCP servers #9989

Open
Open
Pass workspace directory to MCP servers#9989
Labels
enhancementNew feature or requestmcpIssues related to the use of model context protocol (MCP) servers

Description

@ginishuh
ginishuh
opened on Jan 27, 2026

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

Environment

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

Activity

  1. github-actions
    added
    bugSomething isn't working
    extensionIssues related to the VS Code extension
    mcpIssues related to the use of model context protocol (MCP) servers
    windows-osIssues related to Codex on Windows systems
    on Jan 27, 2026

  2. github-actions commented on Jan 27, 2026

    @github-actions
    github-actionsBot
    on Jan 27, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. ginishuh commented on Jan 27, 2026

    @ginishuh
    ginishuh
    on Jan 27, 2026
    Author

    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.

  4. etraut-openai
    changed the title [-]VS Code extension should pass workspace directory to MCP servers (blocking semantic code tools like Serena)[/-] [+]Pass workspace directory to MCP servers[/+] on Jan 27, 2026
  5. etraut-openai
    added
    enhancementNew feature or request
    and removed
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    extensionIssues related to the VS Code extension
    on Jan 27, 2026

  6. drozzy commented on Feb 8, 2026

    @drozzy
    drozzy
    on Feb 8, 2026

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

  7. ub3dqy commented on Apr 14, 2026

    @ub3dqy
    ub3dqy
    on Apr 14, 2026

    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.

  8. FROWNINGdev
    added a commit that references this issue on Jul 24, 2026

    fix(mcp): accept workspace_root arg on all 9 tools + hardened resolution

    9e668b5
  9. WonderMr
    added 2 commits that reference this issue on Oct 9, 2026

    fix(daemon): a bridge's launch directory counts only inside a project (…

    0f4078f

    Daemon: a session's bridge registers its own project, for Claude Code…

    58b0567
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestmcpIssues related to the use of model context protocol (MCP) servers

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions