directory parameter rejects valid absolute paths with "is not an absolute path" error

[MekaretEriker]

Description

When passing a valid absolute path to the directory parameter of opencode_run, opencode_ask, or opencode_fire, the validation rejects it with the error below — even when the path IS absolute and points to an existing directory.
Error: Invalid directory: "/mnt/d/Projects/opencode-agent" is not an absolute path.
Suggestions:

The directory parameter must be an absolute path to an existing directory
Example: /home/user/my-project (not ./my-project or ~/my-project)

/mnt/d/Projects/opencode-agent is absolute (starts with /) and refers to an existing, readable directory containing a valid project.

Environment

• opencode-mcp : 1.10.1 (also reproduced via npx -y opencode-mcp@^1.10.1)
• opencode server : 1.14.48 (healthy)
• MCP client : Claude Cowork (Anthropic desktop app), but reproducible from any MCP client
• Host OS : Windows
• opencode serve runs in : WSL2 (Ubuntu)

Steps to reproduce

1. Have opencode serve running in WSL with a working directory like /mnt/d/Projects/SomeProjectA.
2. Create another directory at /mnt/d/Projects/SomeProjectB (with or without .git).
3. From any MCP client, call:

{
  "method": "opencode_run",
  "params": {
    "prompt": "git status",
    "directory": "/mnt/d/Projects/SomeProjectB",
    "agent": "build"
  }
}

4. Observe the error above. Same behavior with opencode_ask and opencode_fire.

Expected

The directory parameter should accept any absolute path to an existing directory and switch the request's project context accordingly.

Workaround currently in use

Omit the directory parameter and prefix the prompt with an explicit cd:

{
  "prompt": "cd /mnt/d/Projects/SomeProjectB && git status",
  "agent": "build"
}

This works reliably but moves the context-switching responsibility from the MCP transport to the model/shell layer.

Hypothesis

The error message wording (mentioning ~/path and ./relative) suggests the validator was designed to reject those forms — but it appears to incorrectly trigger on valid absolute paths under WSL (/mnt/d/...) or when the target path differs from the opencode server's current working directory. Possibly a regex or path.isAbsolute()-style check that misfires.

Glancing at src/ would be useful — the check is likely in the params-validation layer for the workflow tools.

Why this matters

For MCP clients orchestrating multi-project workflows (delegating tasks across several repos), directory is the natural way to target a specific project per call. The cd workaround pollutes the prompt and isn't transparent for downstream tooling that inspects raw prompts.

[coderabbitai]

⚠️ Possible Duplicate Issue(s)

• normalizeDirectory rejects Windows absolute paths (C:\..., \server\share) #5

🔗 Related PRs

#6 - fix(helpers): accept Windows absolute paths in normalizeDirectory [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[AlaeddineMessadi]

Thanks for the detailed repro — that was enough to pin this down without needing your env.

Root cause

The validator is in src/helpers.ts → normalizeDirectory(). The original (v1.10.1) check was:

const normalized = path.resolve(directory);
if (!normalized.startsWith("/")) {
  throw new Error(`Invalid directory: ... not an absolute path`);
}

That startsWith("/") is POSIX-only. Your opencode-mcp is running on the Windows host, not in WSL — most likely Claude Cowork is spawning npx -y opencode-mcp against the Windows Node. So when you pass /mnt/d/Projects/opencode-agent:

// Node on Windows:
path.resolve("/mnt/d/Projects/opencode-agent")
// → "\\mnt\\d\\Projects\\opencode-agent"
//   (forward-slash absolute paths get reinterpreted as Windows paths
//    rooted at the current drive)

"\\mnt\\d\\Projects\\opencode-agent".startsWith("/")
// → false → throws "is not an absolute path"

So the validator was right that the resolved string isn't a POSIX absolute path — but wrong to assume that's the only valid form when the runtime might be Windows. Your hypothesis was on the money.

Fix already merged on main, not yet released

@samuelgudi fixed this in PR #6 (commit e8e6cfe), which switches the check to path.isAbsolute() from node:path — that's platform-aware and accepts both POSIX (/home/...) and Windows (C:\Users\..., \\server\share) absolute paths. Plus a Windows-runner regression test.

The fix landed on main shortly after the v1.10.1 release tag and has been waiting for a release. Three other unreleased fixes are also on main since v1.10.1 (PR #7 OPENCODE_SERVE_ARGS, PR #8 model variant, plus the in-progress PR #11 SDK migration + parallel projects + assorted hardening).

What this means for you

• Your workaround stays correct in the short term.
• Once the next release ships, your original call with directory: "/mnt/d/Projects/SomeProjectB" will pass validation.
• One caveat to flag: even after the validator is fixed, the path that reaches the OpenCode server will be the Windows-resolved form (\mnt\d\Projects\...), and your OpenCode is running in WSL where the canonical form is /mnt/d/Projects/.... The OpenCode server may or may not normalize this transparently. If it doesn't, a follow-up Windows↔WSL path-translation layer in the MCP would be the right place to handle it — separate issue if it shows up. Worth testing once the release lands.

I'll ping the maintainer to cut a release. Will close this once that's out and you've confirmed the fix.

[AlaeddineMessadi]

Fix is now live: v1.10.2 is on npm.

npx -y opencode-mcp@1.10.2

Or pin in your MCP client config:

{
  "command": "npx",
  "args": ["-y", "opencode-mcp@1.10.2"]
}

What changed

normalizeDirectory now uses path.isAbsolute from node:path instead of startsWith("/"). Your /mnt/d/Projects/opencode-agent call should pass validation. Tag: v1.10.2. Full notes: CHANGELOG.

Caveat to verify

When opencode-mcp runs on a Windows host, path.resolve("/mnt/d/...") produces "\\mnt\\d\\..." — the validator now accepts that (fix lands), but the path that reaches your WSL-side OpenCode server is the backslash form. The server may or may not handle that transparently. Two scenarios worth checking:

1. directory passes validation but OpenCode returns a "project not found" or similar → file a follow-up; we'd add a Windows↔WSL path-translation layer.
2. directory passes and everything works → done.

Could you try opencode_run with the original directory: "/mnt/d/Projects/SomeProjectB" payload (no cd workaround) and report what you see? Closing on confirmation.