Repository navigation
fix(cli): share the device's OpenTunnel tunnel for remote access - #53844
Merged
Merged
Conversation
2 of 6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Issue for this PR
Closes #
Type of change
What does this PR do?
Remote access (#53837) gave OpenCode its own OpenTunnel profile per channel, so a machine that already had a tunnel got a second one and waited on a new certificate. OpenTunnel is designed around one tunnel per device that apps share by claiming their own routes.
The service now uses the device's default tunnel and claims a subdomain route:
opencodeon latest,opencode-<channel>otherwise (for examplehttps://opencode-dev.<id>.opentunnel.xyz). It never claims the tunnel hostname itself, which the opentunnel CLI may route. The tunnel certificate already covers*.<hostname>, so an existing tunnel needs no new certificate. On a machine with no tunnel, enabling remote access creates the shared default one automatically; users never need the OpenTunnel CLI. The setup message no longer mentions OpenTunnel.The old per-channel profile (e.g.
~/.local/share/opentunnel/opencode-dev) is left on disk untouched.How did you verify your code works?
ensurereused it in 238 ms with no setup message and no new profile; the route attached and served the running service (401 without credentials); the opentunnel CLI daemon kept running.XDG_DATA_HOME):ensurecreated the default tunnel in 28 s, the route attached and answered (401 without credentials), then the test tunnel was removed.bun run checkpasses.Screenshots / recordings
N/A (CLI only).
Checklist
— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊