Influxx SSH Hosts, Remote Coding, Browser, and Design Mode
Influxx is built so agentic engineering is not trapped on a single laptop folder. You can attach remote SSH hosts, run workspaces on more powerful machines, keep Windows projects on WSL, open embedded browser tabs per worktree, hand UI elements straight into agent prompts with Design Mode, and let agents operate real desktop apps through Computer Use — all inside one cockpit. This guide covers SSH remote hosts, remote coding, the in-app browser and Design Mode, Computer Use permissions, task and git integrations that feed those remotes, and the CLI surface that scripts the same workflows.
Use this article when you need agents on a beefy box, a Linux distro under Windows, live previews without leaving the IDE, or desktop UI automation that goes beyond a single browser page. Related Influxx topics — worktrees, agents, notes, source control, mobile companion, and privacy — sit alongside these surfaces in product Notes and the ETAPX help center. Stick to shipped behavior: remote execution stays on machines you configure; primary work is local-first unless you deliberately point a project at SSH or WSL.
Point Influxx at a remote host and run agents there with the same cockpit UI — more cores, same workflow.
What remote and browser surfaces cover
Remote Hosts in Settings include SSH Hosts and Remote Influxx Servers (Beta). SSH Hosts give you files, terminals, Git, and workspaces on another machine, with auto-reconnect and port forwards exposed in the Ports panel for SSH repos. On Windows, WSL is a first-class project runtime: choose the Windows host or a WSL distro as default, override per repo, and register the CLI so influxx inside the distro talks to the desktop app. Browser work is worktree-scoped embedded Chromium — not a separate browser app — plus Design Mode / Grab Page Element to send HTML, CSS, and a cropped screenshot into the agent prompt. Computer Use extends that idea to desktop apps and visible UI when a workflow needs real interaction outside the embedded browser.
At a glance:
- SSH Hosts: Attach remote machines for files, terminals, Git, worktrees, reconnect, and port forwards
- WSL: Windows host vs distro runtime, per-repo overrides, WSL CLI registration
- Embedded browser: Chromium tabs per worktree; auto-preview of local dev servers; full CLI automation
- Design Mode: Grab a page element — HTML, CSS, cropped screenshot — into the agent prompt
- Computer Use: Operate desktop apps via accessibility trees, clicks, typing, and related actions
- Integrations: Git providers and Linear/Jira task sources that open workspaces from real issues and PRs
- CLI: Same cockpit surfaces for scripts and agents — status, worktrees, browser, computer, and more
SSH hosts: remote coding without a second IDE
Influxx SSH Hosts are how you keep the cockpit on your desk while code, agents, and terminals run where the hardware lives. Open Settings → Remote Hosts → SSH Hosts to manage machines, or add a remote host from the sidebar when you attach a new machine. When you add a project you can open a local folder, clone a remote URL, import nested multi-repos, or connect an SSH remote host path — the last path is the entry for remote workspaces that feel local in the UI.
On an SSH-backed project, agents run on the remote box with full file editing, Git, terminals, worktree isolation, reconnect after network blips, and port forwards. Relative paths under the worktree (including .influxx/notes and related product files) stay the same as local checkouts; filesystem operations go through the remote connection. The right activity bar includes a Ports panel for SSH repos so you can see and work with forwarded ports without leaving Influxx. Auto-reconnect keeps sessions usable when laptops sleep or networks flap — you resume the same cockpit state instead of rebuilding the environment by hand.
How to attach an SSH host and open a remote project
Open Settings (⌘, on macOS / Ctrl+, on Windows and Linux) and open Remote Hosts → SSH Hosts, or start from the sidebar when attaching a new machine. Add the host with the connection details your environment already uses for SSH access. From Add project, choose a remote host path (or open a repo path on that host) so Influxx tracks it as a project. After import, pick or create a worktree (workspace) the same way you would locally — main checkout for primary work, feature worktrees for isolated parallel agents. Launch agents and terminals in that worktree; they execute on the remote machine while tabs, Source Control, notes, and browser surfaces stay in the single Influxx window.
SSH workflow checklist:
- Register the host: Settings → SSH Hosts or sidebar “add remote host”
- Open a remote path: Add project → connect SSH remote host path / open folder on the host
- Create worktrees: Same New Workspace / worktree create flow as local — isolation is still per checkout
- Run agents on the box: Terminals and CLI agents are worktree-scoped PTYs on the remote runtime
- Use Ports: Right activity bar → Ports for SSH repos (forwards and detected listening ports)
- Expect reconnect: Session recovery after disconnect is part of the SSH host experience
- Keep notes with the tree: Sidebar notes remain files under .influxx/notes on the remote worktree
Remote machines shine when builds, tests, or multi-agent experiments need more cores and memory than your laptop. You still review diffs, annotate lines, commit, push, and open PRs from the same Source Control and PR surfaces. There is no separate “merge worktree” product verb beyond normal Git: ship on the host (GitHub, GitLab, and so on), then delete or archive the workspace in the UI when you are done.
WSL on Windows: host vs distro runtime
On Windows, Influxx lets you choose the default project runtime — Windows host or a WSL distro — and set per-repo runtime overrides when one project should stay native Windows while another must live inside Linux. That matters for toolchains, path conventions, and agent CLIs that expect a Unix environment. WSL CLI registration puts the influxx command on the distro PATH so commands inside WSL talk to the desktop app instead of becoming a disconnected shell tool.
How to set up WSL with Influxx
During first launch (Windows), onboarding includes default terminal shell and related host choices; after install, open Settings and set the default project runtime to Windows host or your preferred WSL distro. For a single repository that should differ from the default, apply a per-repo runtime override. Install or register the CLI from Settings → General / CLI, then use WSL CLI registration so the distro PATH can invoke influxx against the running desktop app. Verify with influxx status (or your platform binary name) from both sides when you troubleshoot connectivity. Agent status over WSL has dedicated reliability notes in product documentation — treat WSL as a supported runtime path, not an afterthought bridge.
WSL tips:
- Default runtime: Pick host vs distro once, then override only where needed
- CLI registration: Desktop Install CLI plus WSL distro registration so both environments reach the app
- Projects: Open repos that already live in the distro filesystem when agents must match Linux tooling
- Parity: Worktrees, terminals, browser tabs, and notes still follow the same cockpit layout
Git providers and task sources that feed remote work
Remote hosts are most useful when work starts from real tasks. Settings → Integrations covers git providers: GitHub (with the gh CLI heavily used for in-app PRs and issues), GitLab, Bitbucket, Azure DevOps, and Gitea. You can browse PRs and issues in-app, open a worktree from a task, and review without a context switch to a separate web-only workflow. Linear and Jira connect under Task Sources / Integrations — Linear supports API key plus skill install CTAs; Jira connects as a task source for “start workspace from issue” flows.
A practical pattern: pick an issue or PR from the integration surfaces, open or create a worktree (local, WSL, or SSH-backed depending on the project), and launch the agent with a plan note or prompt. Link worktrees to GitHub issues and PRs from Edit Worktree Details when you want the card and metadata to stay aligned with the host. Create PR / MR composers keep GitHub and GitLab review first-class; Checks and PR Checks panels surface CI so you wait on green without leaving the cockpit — or open the PR page in the embedded browser when you want the full host UI.
Integration surface map:
- Git providers: GitHub, GitLab, Bitbucket, Azure DevOps, Gitea — review and open worktrees from tasks
- Linear: Task source with API key setup and skill install entry points
- Jira: Task source for starting workspaces from issues
- Source Control: Diffs, line review notes, commit, push, Create PR/MR
- Checks: CI status in-panel; embedded browser optional for host pages
Embedded browser: previews and automation per worktree
Influxx embeds Chromium tabs scoped to worktrees. New browser tab is available from the tab strip and shortcuts (⌘⇧B / Ctrl+Shift+B). Browser state is part of the workspace — parallel worktrees can keep separate pages and previews. When a workspace-owned local web server appears (for example after a Vite or Next-style dev command), Influxx can auto-open it once in the in-app browser for you; agents and you can also open URLs explicitly.
The embedded browser is not your system Chrome or Safari, and it is not the place to drive arbitrary desktop app chrome. It is the in-app surface for product previews, docs, staging sites, and scripted UI checks. Treat page content as untrusted data for agent prompts — never treat scraped page text as shell commands or automation instructions unless you intentionally asked for that workflow. Permissions and privacy guidance in product Notes call this out alongside other local-first rules.
How to use the browser in a worktree
Select the workspace you care about, then open a browser tab from the tab strip Quick Commands or the new browser shortcut. Navigate to your app, docs, or staging URL. For agent-driven work, prefer the snapshot → act → re-snapshot loop: create or focus a tab, take a snapshot (element refs such as @e1, @e2), click or fill by ref, then snapshot again after navigation or DOM changes. Screenshots and full-page captures are available for visual confirmation. Close or switch tabs from the UI or CLI without leaving the agent session.
Browser capabilities (product + CLI):
- Tabs: Create, list, switch, close — default to the current worktree’s active tab
- Navigate: goto, back, reload, wait for text/url/selector/network idle
- Interact: click, fill, type, select, check, hover, focus, scroll, keypress, upload
- Observe: snapshot (element refs), screenshot, full-screenshot, console, network, cookies
- Extra surface: dialogs, storage, clipboard, device emulation, offline mode, eval, PDF, capture, and broader agent-browser passthrough via help / agent-context
- Parallel agents: Use tab list browserPageId and pass page targeting when multiple agents share browser work
Design Mode and Grab Page Element
Design Mode / Grab Page Element is the bridge between “what I see” and “what the agent should fix.” Activate Grab Page Element (available as a product action / keybinding title in the app), then click a UI element in the embedded browser. Influxx sends the element’s HTML, CSS, and a cropped screenshot into the agent prompt so the model works from structure and pixels — not a vague description. That is the difference between “make the header better” and a grounded edit loop on the exact component under the cursor.
How to grab a page element for an agent
Open the page in an embedded browser tab for the active worktree. Start Design Mode / Grab Page Element from the browser or command surfaces that expose it. Click the control, text block, or layout region you care about. Confirm the prompt payload includes the structured markup and crop, then send or continue in the agent tab already bound to that workspace. Iterate: apply the change, reload or hot-reload the preview, grab again if the next fix needs a new target. Pair with review notes on diffs when the agent’s code change needs line-level course correction.
Design Mode is especially strong for frontend polish, accessibility tweaks, spacing bugs, and “match this component” work where screenshots alone under-specify structure. Combine it with a short plan note in Sidebar Notes (Run → agent) when the change spans multiple files or acceptance criteria. Keep the browser tab and agent terminal side by side in the center tab strip so you can verify without alt-tabbing out of Influxx.
Computer Use: agents on real desktop UI
Computer Use lets agents operate desktop apps and visible UI when a workflow needs interaction outside the embedded browser — native apps, system browsers, multi-window tools, or any accessibility-exposed interface the product supports. Open Settings → AI Capabilities → Computer Use for permissions and setup. On macOS, Accessibility and related prompts (including screenshot / screen recording style permissions when required) are managed under Computer Use and Settings → Privacy & Security → macOS Permissions. Agent skills include a Computer Use pack installable from Agent Skill setup so coding agents know the safe CLI contract.
Prefer the embedded browser CLI for Influxx browser tabs; use Computer Use for desktop app windows, external browsers, or UI that is not the worktree-scoped Chromium surface. Agents should list apps and windows, read app state (accessibility tree plus screenshot when available), then act with semantic operations — click by element index, set values on editable fields, type text, press keys, hotkeys, scroll, drag, and secondary accessibility actions. Element indexes are short-lived; after any UI change, re-read state before the next action. Do not push, submit, send messages, buy items, delete data, change account settings, or expose secrets unless you explicitly asked for that action.
How to enable and run Computer Use
Open Settings → Computer Use and complete permission prompts for your OS (macOS Accessibility and screenshot-related permissions are the usual gates). Install the Computer Use agent skill if you want CLI agents to discover the workflow automatically. From a terminal or agent session with the CLI registered, confirm the app is reachable (influxx status), inspect capabilities and permissions, list apps, then get-app-state for the target. Operate with click, set-value, type-text, press-key, hotkey, and related commands, preferring --json for machine-readable results. If a permission error appears, re-open Computer Use / macOS Permissions and retry rather than guessing flags.
Computer Use command family (illustrative):
- Discover: computer capabilities, permissions, list-apps, list-windows
- Observe: get-app-state (tree + screenshot path in JSON workflows)
- Act: click, set-value, type-text, press-key, hotkey, paste-text, scroll, drag, perform-secondary-action
- Selectors: Prefer app bundle IDs; use window-id / window-index when multiple windows exist
- Safety: Sensitive text via stdin flags where supported; never invent destructive actions
Embedded browser for the page inside Influxx; Computer Use for the desktop around it — same agent, clear boundary.
CLI overview for remote, browser, and desktop control
The Influxx CLI lets agents and scripts drive the same cockpit you use by hand — worktrees, terminals, browser, orchestration, computer use, automations, and more. It talks to a running Influxx app (or a headless serve runtime when you run serve for remote/mobile pairing scenarios). Register the CLI from Settings → General / CLI (Install CLI on PATH). On Windows + WSL, use WSL CLI registration for the distro PATH. Examples in docs typically use the influxx command; Linux PATH installs may expose influxx-ide; dev builds use influxx-dev. The command tree is the same.
Start most automation with influxx status --json (and influxx open --json if the app is not running). Prefer --json for agent-driven calls. Print the machine-readable schema with influxx agent-context --json so coding agents discover capabilities without scraping help text. Other useful groups include project, repo, file, automations, environment, computer, emulator, linear, and diagnostics. Browser automation and computer commands share the principle: observe, act, re-observe — never assume stale element refs or window indexes still apply.
How to install and verify the CLI
Open Settings → General / CLI section and run Install CLI to register a launcher on PATH. On Windows with WSL, complete WSL CLI registration so the distro can reach the desktop app. Verify with influxx status (or influxx-ide / influxx-dev for your install). Useful smoke checks include influxx open --json, influxx status --json, and influxx agent-context --json. From there, worktree, terminal, tab/browser, and computer command groups mirror the UI.
CLI recipes that pair with this guide:
- Worktrees: worktree list / create / set / rm / ps — create remote or local checkouts and launch agents with --agent and --prompt
- Terminals: terminal create, send, read, wait (tui-idle), split, switch, close
- Browser: tab create --url, snapshot, click --element @e1, fill, screenshot, goto
- Computer: computer list-apps, get-app-state, click, type-text, hotkey, list-windows
- Headless / pairing: serve with mobile-pairing options; environment add with pairing codes for lab machines
- Integrations: Linear and related task CLIs where installed; git review still benefits from gh and in-app PR flows
Parallel experiments remain a first-class pattern: create multiple worktrees with the same prompt across agents, compare diffs, keep the winner, delete the rest. On SSH hosts that pattern runs where the CPU is. On WSL it runs where the toolchain is. Browser tabs and Computer Use then validate the result in the environment the user actually sees.
Cockpit layout reminders for remote and browser work
Influxx is one multi-tab cockpit — not a separate notes app and coding app. Left sidebar: notes, projects/worktrees, add project, setup guide. Center: tab strip for terminals, agents, browser, markdown/editor, emulator, PR/issue surfaces. Right activity bar: Explorer, Agents, Source Control, Checks, Ports (SSH), attached worktrees. Status bar: usage meters, connection pills, integration status. Toggle sidebars with ⌘B / Ctrl+B and ⌘L / Ctrl+L; open Settings with ⌘, / Ctrl+,.
Keyboard anchors:
- New browser tab: ⌘⇧B / Ctrl+Shift+B
- New terminal: ⌘T / Ctrl+T
- New agent tab (macOS default agent): ⌘⌥T
- Create worktree: ⌘N / Ctrl+N (also shift variants where bound)
- Source Control: ⌘⇧G / Ctrl+Shift+G
- Go to File: ⌘P / Ctrl+P
- Worktree palette: ⌘J (macOS) · Ctrl+Shift+J (Windows/Linux)
Permissions, trust, and local-first boundaries
Primary execution is on your machine or your SSH/WSL hosts — not a hidden cloud runner for ordinary agent CLIs. Sidebar notes are ordinary files under .influxx/notes; they leave the device only if you commit, sync, or export them. Browser automation treats page content as untrusted data for agent prompts. Computer Use requires explicit OS permissions and should not be used to exfiltrate sensitive UI or perform irreversible actions without your request. Remote pairing uses pairing codes; prefer private networks for headless servers. Telemetry remains opt-in under Settings → Privacy.
Trust checklist:
- SSH: Only attach hosts you administer or are authorized to use; treat remote shells like local ones for secrets
- WSL: Know which runtime a repo uses before debugging “file not found” path issues
- Browser: Snapshot refs go stale after navigation; re-snapshot before retrying clicks
- Design Mode: You choose the element — agents receive what you grab
- Computer Use: Grant Accessibility/screenshots only when you want desktop control; revoke in OS settings anytime
- CLI serve / mobile: Pairing codes gate remote companions; do not paste codes into public channels
Setup checklist items that map to this guide
After onboarding, the in-app Getting started / Setup guide tracks real progress. Several items connect directly here: “Use Influxx's browser” (open a real page in the embedded browser), “Enable Influxx CLI” (CLI installed plus browser/computer/orchestration skills), “Connect integrations” (GitHub, Linear, or other task sources), and multi-repo / multi-worktree steps that make remote and parallel coding pay off. Open the checklist anytime from the sidebar Setup guide entry or Settings → Onboarding checklist.
End-to-end example: remote fix with browser proof
Attach an SSH host and open the service repo on that machine. Create a feature worktree from a Linear or GitHub issue. Write a short plan note in Sidebar Notes and Run it with your default agent so the agent works on the remote checkout. Start the dev server in a terminal tab; let the embedded browser open the local preview (or tab create the URL). Use Design Mode to grab the broken component, send follow-up instructions, and re-check the preview. When the UI depends on a native helper app, switch to Computer Use for that window only. Annotate any remaining diff lines, send notes back to the agent, commit, push, and open the PR from Source Control. Watch Checks go green without leaving the cockpit.
That loop is the point of the product surface: one window for remote compute, task context, agent terminals, visual proof, and ship. Whether the worktree path is on your Mac, inside WSL, or on an SSH host, the cockpit regions and CLI verbs stay consistent — so muscle memory transfers and agents can script the same steps you would click.
Troubleshooting quick hits
If SSH workspaces disconnect, use the host’s reconnect behavior and confirm the Ports panel still reflects the services you expect. If WSL commands cannot see Influxx, re-run WSL CLI registration and influxx status from inside the distro. If browser clicks miss, re-run snapshot and use fresh @e refs; open a tab if you see a no-tab style error. If Computer Use returns permission or empty tree errors, fix OS permissions, restore/focus the target window, and re-run get-app-state. If the CLI cannot connect, start or focus the app with influxx open and confirm Install CLI completed for your environment.
Related topics to explore next:
- Worktrees and agents: Parallel checkouts, New Workspace composer, default agents
- Sidebar Notes and Run: Plan files under .influxx/notes and context packs
- Source Control and review notes: Line comments back to agents, Create PR/MR
- Mobile companion: Monitor and steer agents from your phone after pairing
- Privacy and permissions: Local-first model, telemetry opt-in, macOS permission panes
- Orchestration and automations: Multi-agent coordination and scheduled runs via CLI
Influxx ships these remote, browser, and desktop-control surfaces so agentic engineering scales with your hardware and your real UI — not only with chat transcripts. Configure SSH Hosts and WSL when the machine matters; use the embedded browser and Design Mode when the page matters; enable Computer Use when the desktop app matters; wire git and task integrations so work starts from the issue that already exists. Then let the CLI and agents drive the same cockpit you already know.
