[Codex Desktop][Remote SSH] Add a VS Code-like Ports panel for explicit port forwarding management

What feature would you like to see?

Please add a first-class Ports / Forwarded Ports panel for Codex Desktop remote SSH workspaces, similar in spirit to VS Code Remote SSH.

Codex Desktop has started to support automatic SSH port forwarding for remote services used by the built-in Browser, but the forwarding lifecycle is still mostly implicit and difficult for the user to inspect or control.

The missing piece is a user-facing port management surface.

Desired workflow

For a remote workspace:

REMOTE PORTS

Remote           Local             Process / Service     Status
127.0.0.1:5173 -> 127.0.0.1:5173  vite                  Forwarded
127.0.0.1:6006 -> 127.0.0.1:6006  tensorboard           Forwarded
127.0.0.1:7860 -> 127.0.0.1:53142 gradio                Auto
127.0.0.1:8888 -> -                jupyter               Detected

[Forward a Port]

Each forwarded port should expose actions such as:

• Open in built-in Browser.
• Open in system browser.
• Copy local URL.
• Change the local port.
• Stop forwarding.
• Restart forwarding.
• Pin/persist the mapping for the workspace.
• Prefer/reuse an existing SSH forward when one already exists.

Required capabilities

1. Manual forwarding

Allow the user to explicitly create:

remote 127.0.0.1:7860 -> local 127.0.0.1:7860
remote 127.0.0.1:8888 -> local 127.0.0.1:18888

The local port should be user-selectable rather than always dynamically allocated.

This is important for services where origin stability matters, including:

• OAuth callbacks
• CORS
• cookies/session state
• frontend/backend development
• Jupyter
• TensorBoard
• Gradio
• research dashboards

2. Automatic detection

When a command starts a service such as:

Vite       localhost:5173
TensorBoard localhost:6006
Gradio      localhost:7860
Jupyter     localhost:8888

Codex may detect it and offer to forward it.

Automatic forwarding is useful, but it should be visible and controllable rather than silently creating opaque SSH tunnels.

3. Reuse existing SSH forwarding

If the user already has an SSH mapping configured manually or via ~/.ssh/config, for example:

Host gpu
    LocalForward 6006 localhost:6006
    LocalForward 7860 localhost:7860

Codex should detect/reuse that mapping where possible instead of unconditionally starting another:

ssh -N -L <dynamic-port>:127.0.0.1:<remote-port> ...

The UI should distinguish:

Managed by Codex
Existing SSH forward
Auto-forwarded
Manual Codex forward

4. Stable mapping

Users should be able to request:

remote 5173 -> local 5173

instead of receiving a new random local port every time.

A stable local origin is important for browser state, callback URLs, CORS configuration, and links copied between sessions.

5. Lifecycle visibility

The Ports panel should show:

• remote host
• remote bind address and port
• local bind address and port
• connection status
• whether the tunnel is managed by Codex or pre-existing
• optionally the detected process/service
• errors such as local-port conflicts

Closing a Browser tab should not make the forwarding lifecycle impossible to understand.

Remote + Browser integration

The built-in Browser should understand these mappings.

If a remote service is:

remote localhost:7860

and is mapped to:

local localhost:7860

"Open in Browser" should use the correct local forwarded endpoint while retaining the association with the remote workspace.

This should also work for services generated by Codex itself during a task.

Why this matters

For remote development and research, ports are part of the normal workspace:

• web dev servers
• TensorBoard
• Jupyter
• Gradio demos
• experiment dashboards
• local APIs
• model servers
• visualization tools

Codex already provides remote files, shell execution, and an in-app Browser. Port forwarding is the missing bridge between those surfaces.

Without a first-class Ports UI, users still need to leave Codex and manually maintain separate ssh -L commands or VS Code Remote SSH just to inspect remote services.

Relationship to existing issues

This request is broader than the existing port-forwarding reports:

• #21294 — asks for automatic forwarding of remote dev-server ports.
• #32259 — remote Browser localhost should resolve to the remote service / support forwarding.
• #44385 — asks to disable automatic forwarding or reuse an existing local forward.

Those issues describe important pieces of the behavior. This issue proposes the unified product surface around them: a visible, explicit, controllable Ports manager.

Suggested MVP acceptance criteria

1. Remote SSH workspaces expose a Ports panel.
2. A user can manually forward an arbitrary remote port.
3. A user can choose the local port.
4. Active forwards are visible with remote/local endpoints.
5. A forward can be stopped/restarted from the UI.
6. The built-in Browser can open a forwarded endpoint directly.
7. Automatically detected/created forwards appear in the same panel.
8. Existing user-managed SSH forwards are reused or at least detected where possible.
9. Local-port conflicts produce an actionable error rather than silent failure.
10. Forward mappings can optionally persist per remote workspace.

The issue identifies no implementation files or tests. Start by tracing the existing remote SSH, Browser, and automatic port-forwarding behavior, then review related issues #21294, #32259, and #44385. Done means a remote workspace has a visible Ports panel meeting the ten listed MVP acceptance criteria, including manual forwarding, lifecycle controls, Browser integration, reuse or detection of existing forwards, and actionable conflicts.