Open a thread's workspace in VS Code from an iPad or phone through a VS Code tunnel

[DavidPerezA12]

Problem

"Open in" hands off to a desktop editor through a deep link. iPad and phone browsers have no desktop editor, so #27544 reports the failure and #27557 removes the broken option. After that fix, these devices still have no way to open the workspace in an editor from T3 Code.

Proposal

When the server has a connected VS Code tunnel, offer "VS Code (web)" on devices that can't use a desktop editor. It opens https://vscode.dev/tunnel/<name>/<path> in a new tab.

• The server reads the tunnel name from code tunnel status, which reports "name" and "tunnel":"Connected", and advertises it only while connected.
• T3 Code only builds a link. It adds no proxy, no new setting, and no hosted editor. The user starts the tunnel with code tunnel; T3 Code doesn't start or monitor it, unlike Add VS Code tunnel editor support #3721, which added settings and background monitoring.
• The tunnel doesn't depend on an SSH route, so the option also replaces "No SSH route" on these devices.
• Without a tunnel, the menu stays as fix(web): don't offer VS Code on iPad, iPhone and Android browsers #27557 leaves it.
• The scope is the web client. The native mobile app has no open-in-editor today, so it isn't included.

Tested

On an iPad in Safari, with a tunnel running on my Mac, I opened https://vscode.dev/tunnel/macbook-pro/<path to a project> by hand. It connected and showed the project's files, in VS Code's Restricted Mode until the folder is trusted. The same link also connected from T3 Code added to the Home Screen, where iPadOS opens it in an in-app browser rather than in Safari or a separately installed vscode.dev web app. That in-app browser shows iOS's button for continuing in Safari, so T3 Code doesn't need to choose where the page opens.

The first attempts failed with "The workbench failed to connect to the server (Error: Canceled)". Safari was blocking the GitHub sign-in pop-up; once I allowed pop-ups and signed in, it connected. The first sign-in may need a hint.

I have not prototyped the T3 Code change, and I have not tried a link to a single file, which the file preview's menu would need.

Picker behavior

Following the feedback on #3721, a client never sees both a desktop and a web VS Code entry:

Client	Offered
Desktop app	Editors detected on the machine, as today
Browser on a computer with an SSH route	Desktop link, as today
Browser on iPad or phone, with a tunnel	"VS Code (web)"
Browser on iPad or phone, no tunnel	As #27557 leaves it

The option could be a generic "web editor" target rather than something specific to VS Code, to leave room for other editors as #3721's feedback asked.

Alternative considered

Running code serve-web on the T3 server and proxying it needs no tunnel or sign-in, but the VS Code Server license says you may not "combine it with any of your applications for others to use", so I don't propose it.

Questions for maintainers

1. Is this direction and scope acceptable?
2. Should a computer's browser also get the web option when there is a tunnel but no SSH route?
3. If approved, would you accept a small PR on top of fix(web): don't offer VS Code on iPad, iPhone and Android browsers #27557?