Skip to content

feat(cli): pair remotely through OpenTunnel - #53837

Merged
thdxr merged 1 commit into
v2from
opentunnel-remote
Oct 8, 2026
Merged

thdxr merged 1 commit into
v2from
opentunnel-remote

Conversation

@thdxr

@thdxr thdxr commented Oct 8, 2026

Copy link
Copy Markdown
Member

Issue for this PR

Closes #

Type of change

  • Bug fix
  • New feature
  • Refactor / code improvement
  • Documentation

What does this PR do?

Lets the background service be reached remotely through OpenTunnel, and adds opencode pair --remote.

  • New remote service setting (opencode service set|get|unset remote). Enabling it creates the OpenTunnel tunnel in the foreground first, so the restarted service only has to reattach; if creation fails, the setting stays off.
  • When remote is on, the service attaches the tunnel in a background fiber after it starts serving, so startup never waits on it. The SDK reconnects through network failures; a rejected token or failed certificate stops it with one logged error. The tunnel closes with the service scope.
  • The tunnel URL is appended to urls in /api/info while connected. packages/server only gains an optional getter for extra URLs on start(); it knows nothing about OpenTunnel. No protocol or core changes.
  • opencode pair --remote enables remote if needed, waits for the tunnel, and prints only the tunnel's one-time connect link, with the QR code pointing only at the tunnel address.
  • Existing server auth applies to every request over the tunnel; pairing links stay single-use with a 5-minute TTL.

Depends on @opentunnel/client@0.2.0, which was released for this on the same Effect version (4.0.0-rc.112), so there is one Effect copy in the lockfile. bunfig.toml exempts @opentunnel/* from the minimum release age like our other first-party packages.

How did you verify your code works?

  • bun run check passes.
  • New tests: the remote setting (packages/cli/test/service.test.ts) and tunnel URLs appearing in and leaving /api/info (packages/server/test/process.test.ts).
  • Reviewed by a second agent; its findings (shutdown with a pending connect, close ordering, endless retries on fatal errors, no timeout on creation) are fixed here.
  • Not yet run end to end against a real tunnel on opentunnel.xyz.

Screenshots / recordings

N/A (CLI output only).

Checklist

  • I have tested my changes locally
  • I have not included unrelated changes in this PR

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant