SSH tunnels, remote access, and the beta features you can try today

How to enable experimental features

Everything described in this post lives behind a single toggle: Settings > General > Experimental Features. Flip it on and the sub-features appear. Each one has its own toggle so you can pick what you want.

These features are functional and tested, but the interfaces are still evolving and edge cases are still being discovered. That's why they're behind a flag — not because they're unstable, but because we're not ready to lock in the UX. If something feels wrong, confusing, or broken, we genuinely want to hear about it. Open an issue on GitHub or reach out directly.

SSH tunnel manager

The SSH tunnel manager lives in the sidebar and is available without the experimental flag — it graduated to stable in v1.2.0. It lets you define named SSH port-forwarding profiles and keeps them alive automatically.

Each profile specifies a host, local/remote port pair, and optional SSH key. TUICommander supervises the tunnel with exponential backoff (1s to 30s, with jitter) and classifies exit reasons — auth failure, host key mismatch, port conflict, network timeout — so the UI shows you what happened instead of a generic "disconnected."

The sidebar shows each tunnel with a status badge: green for connected, yellow for reconnecting, red for failed. Click to edit or view the audit log. Every connect, disconnect, and error is recorded in a local SQLite database.

The primary use case is port-forwarding to a tuicommander-remote daemon on a server you can only reach via SSH. But the tunnel manager is generic — it forwards any port for any service.

tuicommander-remote: your backend, anywhere

tuicommander-remote is a headless Rust binary that runs the TUICommander backend without the desktop shell. Install it inside WSL, a Docker container, or a remote server, and the desktop app connects to it over HTTP/WebSocket — driving terminals, agents, git operations, and the MCP bridge as if everything were local.

We wrote a deep dive on tuicommander-remote that covers the architecture, the WSL/Docker/remote use cases, and the security model. The short version: the same Axum routes that power the PWA now power remote access, so there's no new protocol to learn or debug.

What's in beta right now:

• Connection manager UI — Add remote hosts in Settings > Services, with health polling and status indicators.
• Transport routing — Tag a repo with a connection. All terminal, git, and agent operations for that repo route through the remote daemon.
• SSE event bridge — Real-time events (agent status changes, file watcher triggers) stream back to the desktop over Server-Sent Events.
• Protocol versioning — Desktop and daemon negotiate a protocol version on connect, so mismatched versions fail loudly instead of silently.

What's coming next: tuic remote install <host> — a single command that copies the binary, generates a pairing token, and registers the connection. The goal is that adding a new environment takes 30 seconds, not a checklist.

AI Triage: code review that reads the diff

AI Triage takes a git diff — staged, unstaged, or between branches — and classifies every changed file by risk, relevance, and category. It streams results as the LLM works through the changes, so you see the first assessments within seconds even on large diffs.

The intended use: before you commit or open a PR, triage the diff. It catches the files you forgot to look at, flags the ones where a one-line change has outsized blast radius, and groups everything so you review in priority order instead of alphabetical.

Enable it under Settings > General > Experimental Features > AI Triage. The triage button appears in the command palette and in the git panel toolbar. You can customize the system prompt in Settings > Agents > AI Prompts.

AI Watchers: terminals that watch themselves

Watchers are rules you attach to a terminal session. Each rule has a pattern (regex or plain text) and an action — notify, run a command, or trigger a smart prompt. When the terminal output matches the pattern, the action fires.

The simplest use case: watch for error or failed in a CI terminal and get a desktop notification. A more advanced one: watch for a test failure pattern and auto-trigger a smart prompt that analyzes the failure and suggests a fix.

Each watcher has a configurable cooldown (minimum seconds between consecutive fires) to prevent notification storms on chatty output. The watcher toolbar button appears next to the terminal search when the feature is enabled.

Enable it under Settings > General > Experimental Features > AI Watchers.

AI Chat: conversation alongside the terminal

The AI Chat panel gives you a conversational interface alongside your terminals. It has access to your current repository context — file tree, git state, recent changes — so you can ask questions about the codebase without leaving TUICommander.

This is the earliest of the experimental features. The interface and the context it has access to are both evolving. We're particularly interested in feedback on what context should be automatically included vs. explicitly attached.

Enable it under Settings > General > Experimental Features > AI Chat.

Your feedback shapes what ships

Every feature behind the experimental flag is there because it works but isn't finished. The best way to help us finish it is to use it and tell us what's wrong.

• Something crashed or behaved unexpectedly? Open an issue on GitHub with the steps to reproduce.
• The UX is confusing or friction-heavy? Tell us what you expected vs. what happened.
• A feature is close but missing one thing? That's the most valuable kind of feedback — it tells us what to prioritize.

Features that get used and reported on graduate to stable. Features that don't stay behind the flag. Your testing directly decides which is which.