Default cwd should does not work for opencode desktop

[jessielaf]

Problem

When opencode is launched as the macOS desktop app (via Finder, Dock, or Spotlight), the claude CLI subprocess spawned by this plugin runs with its working directory set to / instead of the project directory.

opencode itself shows the correct project in its UI (e.g. ~/projects/foo/foo), and models that don't go through this plugin (tested with non-claude-code providers in the same opencode session) operate against the correct project directory. Only the Claude CLI subprocess ends up at /.

File operations, .claude/ discovery, and CLAUDE.md lookup all resolve against / as a result.

Reproduction

1. Install the opencode desktop app on macOS
2. Add @khalilgharbaoui/opencode-claude-code-plugin to opencode.json
3. Launch opencode from Finder/Dock (not from a terminal)
4. Open any project, e.g. ~/projects/foo
5. Ask Claude to run pwd. It reports /.
6. Switch the model to a non-claude-code provider in the same project. File operations resolve correctly against the project directory.

What I think is happening

GUI-launched apps on macOS inherit / as their working directory from launchd. The plugin's cwd option defaults to process.cwd(), which in this case is /. Launching opencode from a terminal (cd ~/project && opencode) avoids the issue because the shell sets cwd before the process starts, but that's not workable when using the desktop app.

Other providers in opencode seem to handle the project directory correctly somehow, so opencode clearly knows where the project is. I haven't dug into the plugin source to confirm exactly where the fallback happens, so I might be off on the details.

Workaround

Adding a per-project opencode.json with an explicit cwd works.

{
  "provider": {
    "claude-code": {
      "options": {
        "cwd": "/absolute/path/to/project"
      }
    }
  }
}

AI Suggestion

This section was drafted with help from an AI assistant and may be inaccurate, treat as a hypothesis rather than a verified fix.

According to the opencode plugin docs, the plugin context object passed to the plugin factory includes directory, worktree, and project.root, all of which point to the active project. The fix could be to read from that context when resolving cwd, instead of falling back to process.cwd().

Roughly something like.

cwd: options.cwd ?? ctx.directory ?? ctx.project?.root ?? process.cwd()

Environment

• opencode desktop app (macOS)
• @khalilgharbaoui/opencode-claude-code-plugin (latest)
• Claude Code CLI at ~/.local/bin/claude

[khalilgharbaoui]

Hey @jessielaf — thanks for the detailed write-up, the clean reproduction, and the explicit AI-section caveat. Your analysis was exactly right.

Root cause: the plugin defaulted cwd to process.cwd() whenever options.cwd wasn't set in opencode.json. On macOS GUI launches (Dock/Finder/Spotlight), launchd hands the parent process cwd=/, so the Claude CLI subprocess inherited / — while opencode itself knew the real project directory via its plugin context. That matches every symptom you described, including why non-claude-code providers in the same session resolved files correctly.

Fix: the plugin now reads directory (with worktree as a secondary signal) from opencode's plugin context in the server() hook and uses it as the default cwd for the spawned Claude CLI. An explicit options.cwd in opencode.json still takes precedence, so your per-project workaround keeps working if you want to pin it.

• Commit: adcd251 (`Fix cwd fallback for opencode desktop GUI launches (Default cwd should does not work for opencode desktop #4)`)
• Release: v0.2.4 — already on npm as `@khalilgharbaoui/opencode-claude-code-plugin@0.2.4`

Please upgrade (clearing opencode's plugin cache at `~/.cache/opencode/node_modules` if your install pinned the old version), relaunch opencode from the Dock, and the per-project `cwd` override should no longer be necessary. You should also see the resolved `cwd` in the `registered claude-code provider` log line at startup, which makes future regressions of this kind much easier to spot.

Closing as completed — please reopen if anything still misbehaves on your setup.

[jessielaf]

@khalilgharbaoui

Maybe my analysis was wrong. I now get the same cwd everywhere:

[khalilgharbaoui]

Hey @jessielaf, you were right, this regressed differently. Sorry for the bounce.

Decoded screenshot: you've got MonoStack (svelte-monorepo) selected in opencode but Claude reports payqual/payqual-imports for its cwd. That's whichever workspace you opened first this session. Claude is locked to it regardless of which workspace you switch to in opencode's UI.

Root cause of the regression: the v0.2.4 fix captured opencode's directory once at plugin init (inside server()) and froze it into the provider's default cwd. Spawn-time resolution is this.config.cwd ?? process.cwd(), and by setting this.config.cwd permanently I disabled the process.cwd() lazy fallback that previously made workspace-aware behavior work. Workspace switching in opencode's UI never updates a value that was baked at plugin init.

Fix (going into v0.4.21): the captured directory becomes a spawn-time fallback used only when process.cwd() is unusable (i.e. /), not a frozen config value. Resolution chain:

1. Explicit options.cwd in opencode.json (still wins, your old workaround keeps working).
2. Live process.cwd() when it's a real directory (lazy resolution restored).
3. Captured directory from plugin init (rescues fresh macOS GUI launches at /).

If desktop opencode doesn't chdir on workspace switch, this still won't update mid-session and your screenshot would replay. If that's what you see on v0.4.21, please drop a comment. I'll wire up an event-hook listener on workspace changes or a per-request directory query through the runtime client. I'd rather not ship that complexity speculatively.

Reopening until v0.4.21 lands. Thanks for the screenshot, made the diagnosis unambiguous.

[khalilgharbaoui]

v0.4.21 is live on npm. Could you upgrade and try the workspace-switch flow again?

The fix: resolveSpawnCwd (in src/runtime-status.ts) now consults process.cwd() lazily at every Claude CLI spawn, so opencode's chdir on workspace switch flows through to the subprocess. The captured directory from plugin init is kept as a fallback only when process.cwd() is unusable (/), preserving the v0.2.4 win for fresh macOS GUI launches.

Update steps:

# clear opencode's plugin cache so the new version gets fetched
rm -rf ~/.cache/opencode/node_modules
# relaunch opencode (from Dock for the GUI repro)

Test path: open MonoStack, ask Claude wat is je cwd. Then switch to a different workspace in opencode's UI and ask again. The cwd should update to match the workspace you're currently on.

If it still doesn't update on workspace switch, that's the case where macOS desktop opencode isn't calling chdir per workspace switch (only on initial launch). Please drop a fresh screenshot and I'll wire up tier-two: either an event-hook subscription to opencode's workspace-change events, or a per-request directory query via opencode's plugin client. Both are doable, I'd just rather see real evidence before shipping speculative complexity.

Commit: 96b8e8f. Tests: test-cwd-resolution.ts covers the resolution chain (9 cases). Thanks for the patience.