Non-interactive commands need --dir flag for running from source against a different project

[aspiers]

Problem

When running OpenCode from source via bun dev, non-interactive subcommands like mcp add, mcp auth, mcp list, etc. have no way to specify the target project directory. They all hardcode directory: process.cwd() in their handlers.

This is a problem when running from source because bun dev (and the underlying bun run --cwd packages/opencode ...) must be invoked from within the opencode repo. That means process.cwd() resolves to the opencode repo itself, not the user's actual project.

Context

The interactive TUI already has a [project] positional argument (bun dev <directory>), and the run command has a --dir flag. But none of the non-interactive subcommands support any equivalent.

This is related to #6780 and #6404 (missing docs for running from source), since those issues addressed the TUI and desktop cases but not non-interactive commands.

Motivating use case

I needed to trigger the OAuth flow for an MCP server (Notion) configured in my project's opencode.json. The mcp auth command needs to resolve the project config to find the MCP server definition, but when running from source it resolves the opencode repo's config instead.

The same problem would affect:

• mcp add — writes config to the wrong opencode.json
• mcp list / mcp debug — reads the wrong config
• mcp logout — operates on the wrong project context

Other non-interactive commands (agent, models, pr, github, export, import, stats, etc.) share the same process.cwd() pattern, but in practice the pain is most acute for mcp subcommands since they depend heavily on project-specific config.

Steps to reproduce

1. Clone the opencode repo and run bun install
2. Have a separate project with an opencode.json that configures an MCP server
3. Try to run mcp auth from source against that project — there is no working approach

The only workaround I found was:

# Copy opencode.json into the opencode source tree
cp /path/to/my-project/opencode.json /path/to/opencode/packages/opencode/

# Run from within the opencode source tree
cd /path/to/opencode
bun run --conditions=browser --cwd packages/opencode src/index.ts mcp auth notion

This is awkward because:

• It pollutes the opencode source tree with project-specific config
• The project context (git root, config resolution) resolves to the opencode repo, not the target project
• Config written by mcp add would end up in the wrong location

What bun run --cwd does vs what's needed

bun run --cwd packages/opencode tells bun which directory to resolve the script from — it does not affect process.cwd() as seen by the running Node/Bun process in the way that's needed here. The opencode CLI needs its own mechanism to set the logical project directory.

Proposed solution

Add a --dir (or --cwd) option to non-interactive subcommands, consistent with how run already supports --dir. The handler would pass args.dir ?? process.cwd() to Instance.provide({ directory: ... }).

Something like:

// In each non-interactive command's builder:
.option("dir", {
  type: "string",
  describe: "project directory to operate in",
})

// In each handler:
await Instance.provide({
  directory: args.dir ?? process.cwd(),
  async fn() { ... }
})

This would also be useful for the installed opencode binary (not just dev from source), for scripting and CI use cases.

Workaround

Copy opencode.json into the opencode source tree and run from there:

cd /path/to/opencode
cp /path/to/my-project/opencode.json packages/opencode/
bun run --conditions=browser --cwd packages/opencode src/index.ts mcp auth notion

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• No issue template was used. This issue appears to be a feature/enhancement request, so please use the Feature Request template. The title should start with [FEATURE]: and the issue should include the required verification checkbox.
• If this is intended as a bug report instead, please use the Bug Report template which requires a Description field and reproduction context.

Please edit this issue to address the above within 2 hours, or it will be automatically closed.

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.

Feel free to open a new issue that follows our issue templates.