fix(cli): preserve remote launch directories - #47818

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

@jlongster The body already has Closes #47665, but the issue check only reads closingIssuesReferences, which is empty for this v2 PR. Could you link it manually and approve the fork CI when you review it?

The CLI regressions and related TUI tests pass locally, as do the pre-push typechecks. I've also left the branch on #47665 for the reporter to try with their remote setup.

Independent corroboration from a real cross-machine setup, since the PR notes the tests stop at a local HTTP fixture rather than a true remote run.

Setup: Linux client to a Linux central server over an SSH tunnel, attaching with --server http://127.0.0.1:PORT /srv/projects/example, where that path exists only on the server. Before the change: ERROR: ENOENT: no such file or directory, chdir '/home/user' -> '/srv/projects/example', matching the report exactly.

We hit this independently and arrived at the same two call sites as this PR. Confirming the second half is essential: skipping chdir alone is not enough, because the TUI still sends the client's process.cwd().

Also worth recording: process.cwd() resolves symlinks to their physical target, so a client-side symlink is not a viable workaround, only a bind mount reproduces a matching path. That rules out the obvious user-side mitigation and is a good argument for fixing it in the client.

One addition we made that this PR doesn't cover: TuiPathsProvider in app.tsx still passes cwd: process.cwd(), which feeds frecency path resolution and the workspaces-dialog location fallback. On a remote attach those resolve against the client's cwd rather than the project directory. We set it to the same forwarded directory.

We also initially kept the original Effect.catch(() => api.location.get()) fallback. In our case fs/list succeeded so it never fired, but silently landing on the server's default project is a genuinely confusing failure mode, so the explicit Effect.fail here looks like the right call.

Happy to run the branch on this setup if that's useful.

Updated in 8bdbdb9. TuiPathsProvider now uses the server-resolved launch directory instead of the client process.cwd(), so cwd-scoped tab state and other client-side path consumers stay on the attached project. I added coverage for storing tabs under a remote launch directory, updated the branch to current v2, and reran the TUI suite (1,347 passing, 2 skipped) plus the full pre-push lint/typecheck. @kernel-oops The branch is ready if you still have the SSH-tunnel setup available for another run.

Tested 8bdbdb929 on the cross-machine setup. Thanks for folding in the TuiPathsProvider change.

The directory fix works. I ran the branch build as a client on a separate machine, from $HOME, targeting a directory that exists only on the server — verified absent on the client first. No ENOENT, no chdir error. Since process.chdir() throws before any network call, getting past it at all is direct evidence the fix holds off a local filesystem.

But I could not complete a full attach, and I think this is a separate issue worth knowing about. The client fails its preflight with:

Error: Server at http://<host>:<port> did not provide a compatible V2 health response
  [cause]: ClientError: UnsupportedContentType

GET /api/health returns 404 on the server in both cases I tried:

• a 2.0.8-based server (my usual setup), and
• a build of this branch itself, run as a plain opencode serve --hostname 127.0.0.1 --port <port>

So it is not version skew between the client and an older server — the branch's own build does it too. It looks like the client's health preflight expects a surface that a manually started opencode serve does not expose, perhaps assuming the managed background service.

That matters for this PR's use case specifically: --server <url> <dir> against a manually run server is exactly the remote-attach topology, and the preflight rejects it before the directory handling is ever exercised end to end. Happy to gather more detail on the health check if that would help, or to retest once there is something to try.

For completeness, the chdir behaviour was verified on a genuinely remote-only path; everything after that point is blocked by the health preflight rather than by anything in this change.

Good to have the remote-only directory case checked. I looked at the current branch before chasing the preflight separately: the client calls server.info, whose generated request is GET /api/info, and the server registers that same route. It does not request /api/health. Could you check the exact GET /api/info response through the same tunnel, and include the client executable/version you ran? If /api/info is also 404 against a freshly started branch server, that is a separate remote-serve issue worth isolating, but I would rather not mix it into this directory fix without that reproduction.

@jlongster This should be ready for review now. The branch has an independent cross-machine check using a directory that exists only on the server; the local chdir failure is gone, and the TUI path follow-up is included. The branch is mergeable and the checks are green. It still has needs:issue even though the PR closes #47665; if you take a look, could you clear that label as well?

Follow-up on the preflight question: that failure was our setup, not this branch. Our server required a password and the client wasn't sending one. The 401 comes back with an empty body, which the client reports as "did not provide a compatible V2 health response" / UnsupportedContentType. /api/health was a red herring; the client only calls /api/info.

Retested 8bdbdb929 (client and opencode serve both built from it, on Linux):

• /api/info returns 401 without the password and 200 with it.
• With OPENCODE_PASSWORD set, the client passes the preflight, and the server records the requested launch directory as the project rather than falling back to its default.

Together with the earlier remote-only chdir check, the branch works end to end for us.

Separately, a 401 surfacing as an incompatible health response is misleading; that seems worth its own issue.

Automated PR Cleanup

Thank you for contributing to opencode.

Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions.

This PR was closed because it matched the following cleanup criteria:

• The PR was created more than 1 month ago
• The PR had fewer than 2 positive reactions
• Positive reactions are counted as thumbs-up, heart, celebration, or rocket reactions on the PR

PRs created within the last month are not affected by this cleanup.

If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate.

Thanks again for taking the time to contribute.