Verify wmux locally, publish its browser endpoint deliberately, and keep remote monitoring within a clear security boundary
wmux is an open-source agent development environment for running CLI-based AI agents in persistent local workspaces. The project provides a wmux web endpoint and confirms that it binds to loopback by default, which keeps it local until you explicitly choose another access path. This guide covers supported installation routes, local startup and verification, lifecycle behavior, troubleshooting, and a complete Localtonet HTTP tunnel workflow. Because current primary wmux material does not establish authentication or every interaction limit of the web interface, the public-access steps use a temporary, nonsensitive test workspace unless you have separately verified an effective access restriction.
📋 What's in this guide
What wmux provides and where its web endpoint fits
wmux describes itself as an agent development environment, or ADE, for AI agents. It places CLI agents in separate panes and organizes their terminals, Git worktrees, browser activity, and communication channels into workspaces. A background daemon on the user's computer owns those workspaces, so closing the visible desktop window is not the same as discarding every pane.
The current wmux project material identifies Windows and macOS as its primary native desktop platforms. Windows uses ConPTY directly, so WSL is not required. macOS uses forkpty. The project says compatible CLI agents can run next to one another in separate pseudo-terminals, including Claude Code, Codex CLI, Gemini CLI, Aider, OpenCode, and GitHub Copilot CLI. An agent still needs to be installed, configured, and authorized independently. wmux does not supply credentials for those external tools.
wmux also supports restoring workspace information after a reboot. Current primary documentation says that workspaces, panes, working directories, scrollback, and channel history are persisted. It also clarifies that agent processes stop when the computer stops. Restoration brings back the workspace in which a process was running, not a process that somehow continued while the machine was powered off. Panes declared as supervised services in wmux.json may have different restart behavior, but that is a wmux project configuration concern rather than a property of the Localtonet tunnel.
For browser access, the project exposes a wmux web command and states that wmux web binds to loopback by default. Loopback binding means the listener is intended to accept connections originating on the same computer. This is a useful default because it does not automatically create a service reachable through the computer's LAN address.
Current primary evidence supplied for this guide does not establish a universal port, built-in web authentication, a complete list of command options, or a guarantee that every part of the interface is read-only. Treat the endpoint as a browser view whose exact capabilities depend on the installed release. Test its behavior locally instead of assuming that an older description applies to the current version.
This tutorial connects a Localtonet HTTP tunnel to the loopback web endpoint. It does not replace wmux's native iPhone pairing protocol. If you need the companion application's question-and-answer workflow, follow the Remote area in wmux and its documented HTTPS over Tailscale pairing process.
Prerequisites and platform choices
Start with the computer that will actually host the wmux workspace. Current wmux material lists Windows 10 build 1903 or later on x64 hardware and macOS on Apple Silicon as the primary desktop requirements. The project estimates approximately 4 GB of RAM and a few hundred megabytes of disk space as minimum resources. AI agents, repositories, browsers, build tools, and test suites can require substantially more.
Linux AppImage, DEB, and RPM packages are available from the official release area, but the project describes Linux support as experimental. That qualification applies to the complete local stack, including the desktop application, daemon, command-line entry point, and web endpoint. Establish a reliable local workflow before depending on an experimental installation for remote observation.
You also need at least one compatible CLI agent if you want to use wmux for its primary purpose. Install and authenticate that agent according to its own official instructions. Keep credentials out of terminal output. Anything printed in a pane may become visible through a browser endpoint, even if the page does not accept terminal input.
| Platform | Official installation route | Important qualification |
|---|---|---|
| Windows x64 | WinGet, Chocolatey, or the Setup.exe download from the official wmux site | Windows 10 build 1903 or later is documented. The direct installer currently uses a SignPath test certificate and may trigger an unknown-publisher SmartScreen warning. |
| Apple Silicon macOS | Download the official DMG, open it, and drag wmux into Applications | The macOS build is documented as Developer ID signed and notarized. |
| Linux | Use an AppImage, DEB, or RPM from the official GitHub releases page | Linux support is experimental, and package-specific details can vary by release and distribution. |
| iPhone | Install the optional wmux companion from the App Store | The iPhone application is a companion client. It is not a host for wmux web. |
Official wmux locations
- Use the official wmux website and download page for the current Windows installer, macOS download, system requirements, and product documentation.
- Use the official wmux GitHub project to inspect the source, README, project documentation, and license.
- Use the official wmux releases page for current release notes and experimental Linux packages.
Prefer those current project locations over filenames copied from an older tutorial. Release versions and asset names change. The official wmux homepage showed a newer Windows build than one of the individual release pages available during this review, which is why this guide does not hardcode a versioned installer URL.
Localtonet prerequisites
Localtonet is not required for local wmux operation. Install wmux, create or open a workspace, start the web endpoint, and verify it in a browser first. For the remote stage, install and run the Localtonet client on the same computer whenever possible. Co-locating the two processes allows our client to reach wmux through loopback without broadening the wmux listener to the LAN.
The Localtonet device has a device-specific authentication token. Treat it as a credential. Do not put it in screenshots, terminal examples, public issue reports, repositories, or shared support logs. During tunnel configuration you will also select an available relay server or region from the current dashboard rather than copying an old server code.
A tunnel cannot repair a service that is not installed, has exited, or is listening on a different port. Verify the exact loopback address emitted by your installed wmux release before configuring Localtonet.
Install wmux on your computer
Choose one installation method and let that method own the installation. Installing through a package manager and then adding another direct-installer copy can make it unclear which executable a terminal is launching or which copy receives updates.
Install on Windows with WinGet
The official project recommends WinGet on Windows. Open PowerShell or Windows Terminal and run:
winget install openwong2kim.wmuxWait for WinGet to finish, then launch wmux from the application launcher. If WinGet reports that the package is already installed, use its normal package inspection or upgrade workflow rather than repeatedly installing another copy.
Install on Windows with Chocolatey
If Chocolatey already manages software on the computer, use the documented package:
choco install wmuxFollow the prompts and local package-management policy. The project states that WinGet, Chocolatey, and its PowerShell installation route install the same Windows build. Use one package-management route for routine ownership.
Install with the Windows Setup.exe download
Open the official wmux download page and select the current Windows download. Verify that the filename and origin are the ones presented by the official project before launching it.
wmux currently states that the direct installer is signed with a SignPath test certificate, so SmartScreen may display an unknown-publisher warning. Do not dismiss a security warning automatically. Confirm the origin and intended file first. The project recommends a package-manager installation when available because it avoids that specific SmartScreen experience.
Install on Apple Silicon macOS
Download the current DMG from the official wmux site, open the disk image, and drag wmux into Applications. The project identifies this package as signed and notarized and currently documents macOS support for Apple Silicon.
On first launch, wmux installs its CLI onto PATH. If an already-open shell cannot find wmux, close that terminal and open a new one so it receives the updated environment. Do not create an improvised system-wide symlink unless current project documentation specifically identifies that as the appropriate repair.
Install an experimental Linux package
Open the official releases page and select the current AppImage, DEB, or RPM intended for your environment. Follow your distribution's established local-package process.
The supplied project evidence does not establish one universal Linux command, package filename, dependency list, or desktop-integration procedure. Providing a generic guessed command could install the wrong file or hide a release-specific requirement. Test the desktop application and CLI separately after installation.
Complete first launch
Open wmux and create or open a workspace. Confirm that panes render correctly and that ordinary terminal commands work. If you plan to supervise an agent, start that agent in a pane and verify its own authentication and permissions locally.
Detection of an agent CLI does not install it or authorize access to its service. It also does not make every action safe. Review agent permissions, repository scope, browser access, and approval settings independently before making any workspace remotely visible.
Start the wmux web endpoint
After the desktop application and a test workspace work normally, open a terminal on the same computer and run:
wmux webRead the command's complete output. Current primary material confirms the web feature and its default loopback binding, but the evidence supplied for this tutorial does not establish a fixed port or a universal printed URL. Use the address reported by the installed version. Do not substitute a port copied from an old issue, release, or third-party tutorial.
Keep the command running during the test unless your installed release explicitly documents another service mode. If it exits, preserve the error text and solve that local problem before working on a tunnel.
Open a safe test workspace
Use a temporary workspace containing harmless terminal output. Do not begin with a production repository, customer environment, credential prompt, or pane displaying confidential data.
Run the documented web command
Run wmux web in a terminal on the wmux computer and keep the terminal available for startup messages and errors.
Record the emitted address
Record the exact loopback host and port reported by the installed release. These values become the Localtonet target later.
Keep the endpoint running
The browser endpoint can respond only while the wmux web process and the underlying local environment remain available.
The current primary evidence supplied here confirms loopback binding but does not establish every web-interface behavior. Test whether your release exposes controls, and check its current documentation for authentication or access restrictions. Even a view-only page can reveal source code, prompts, command output, filenames, hostnames, internal URLs, or credentials printed by another process.
Verify the interface locally before tunneling it
Open a browser on the wmux computer and enter the exact URL reported by wmux web. The command's output is authoritative for the current run. If the browser cannot connect, stay at this layer until the local endpoint works.
Confirm that the intended workspace or pane appears. Add a harmless, recognizable line to a test pane and check whether the browser reflects it. This helps distinguish the current wmux endpoint from a stale tab or an unrelated local process using another port.
Also test the interface's actual interaction behavior. Do not rely on the previous article's unqualified description of the page as read-only. If the interface accepts input, exposes actions, or displays broader workspace data than expected, account for that before considering public access.
Local acceptance checklist
- The wmux desktop application opens without an installation error.
- The intended test workspace exists and its panes render correctly.
- The agent CLI, if used, works locally with the intended account and permissions.
wmux webremains running and reports a loopback address.- A browser on the same computer opens that exact address.
- The page displays the expected harmless test content.
- You have checked whether the current page permits any interaction.
- No secrets, private source, customer information, or production output are visible.
Keep the loopback boundary
Do not broaden the wmux bind merely to simplify the next step. When our client runs on the same computer, it can connect to the loopback target directly. wmux can therefore retain its default local boundary while Localtonet handles the separate public route.
In this design, wmux serves the endpoint locally. The Localtonet client establishes an outbound connection to a relay server and forwards requests from an assigned public address to the selected local host and port. The standard workflow does not require inbound router port forwarding, a public IP address, a VPN, or an inbound firewall change.
Operate and maintain the local wmux environment
Treat the desktop application, daemon, individual agents, web endpoint, and Localtonet tunnel as separate lifecycle layers. One layer can be available while another is stopped. A restored pane does not prove that its former process is alive, and an open desktop application does not prove that wmux web is listening.
Understand what persistence means
Current wmux documentation says that its daemon persists workspace structures, panes, working directories, scrollback, and channel history. The project also states that agent processes stop when the machine stops. After reboot, inspect the restored workspace and restart any process that has not returned through an explicitly configured supervision mechanism.
The supplied evidence does not promise automatic startup for wmux web. After a restart, run an operational check instead of assuming that the old public path is healthy. Confirm wmux, the required agents, the web endpoint, the emitted port, the Localtonet client, and the tunnel status in that order.
Handle updates deliberately
The project states that Windows x64 and macOS arm64 builds check for a release every 30 minutes and verify it against a published SHA-256 before installation. That statement applies to the current documented desktop builds and should not be generalized to every experimental Linux package.
Automatic update support does not eliminate operational review. Read important release notes before relying on an updated build for unattended monitoring. Web command behavior, daemon behavior, user-interface presentation, and experimental platform support can change between releases.
Separate observation from authorization
A browser view does not change what an agent is permitted to do on the host. Repository access, shell privileges, browser profiles, external service credentials, and approval gates remain properties of the local environment. Configure those permissions according to least privilege.
Likewise, Localtonet provides reachability to the selected endpoint. It does not convert the underlying application into an authenticated application or decide what the displayed workspace should contain.
Configure a Localtonet HTTP tunnel for wmux
Use an HTTP tunnel because the target is a browser-oriented HTTP service. A raw TCP or UDP tunnel is not required for this workflow. VPN Manager is also a separate Localtonet feature and should not be confused with standard HTTP tunneling.
Before proceeding, make a deliberate exposure decision. If you have not verified authentication or another effective access restriction for the resulting endpoint, use only a temporary, nonsensitive test workspace. Do not expose a real agent workspace and do not treat a random or difficult-to-guess public URL as authorization.
Choose the HTTP Process Type
Localtonet HTTP tunnels offer three Process Type choices. All three serve the selected local content through a public HTTPS address:
| Process Type | What it selects | Use in this tutorial |
|---|---|---|
| Random Sub Domain | A generated Localtonet subdomain | The simplest choice for a temporary test when no stable hostname is required. |
| Custom Sub Domain | A selected subdomain where the current dashboard and plan support it | Use only when you intentionally need a recognizable Localtonet hostname. |
| Custom Domain | A domain you control | Use only after checking the current Localtonet DNS instructions. This tutorial does not guess DNS records. |
Process Type changes the public hostname arrangement, not the local wmux target. In every case, the target remains the exact loopback IP address or hostname and port emitted by wmux web.
Follow the HTTP tunnel configuration sequence
Install and run the Localtonet client
Install the client for the host operating system and run it on the wmux computer. Keeping both services on one computer lets the tunnel target wmux through loopback.
Open the HTTP Tunnel configuration
In the Localtonet dashboard, go to the HTTP tunnel area and begin an HTTP tunnel configuration for the verified wmux endpoint.
Select the Process Type
Choose Random Sub Domain, Custom Sub Domain, or Custom Domain. For a short, nonsensitive validation session, a generated subdomain avoids adding custom-domain DNS work.
Select the wmux host device
Select the AuthToken belonging to the Localtonet client running on the wmux computer. Confirm that you selected the intended connected device, and never disclose the token value.
Select an available relay server
Choose a server or region offered by the current dashboard. Available values can vary, so use the live selection rather than a server code copied from an article.
Enter the local IP address and port
Enter the loopback host and exact port reported by the current wmux web process. Do not use a guessed default, an old run's port, or the computer's LAN address.
Create the tunnel configuration
Complete the configuration so the HTTP tunnel exists in the dashboard. Creation records the tunnel settings, but it does not mean the tunnel is running.
Start the tunnel
Use the Start control. Wait for the tunnel to be running and confirm that the selected Localtonet client remains connected.
The full configuration workflow is also available in our Localtonet HTTP tunnel documentation. The essential target fields are the local IP address and port, while Process Type determines how the public HTTPS hostname is assigned.
Test, stop, and delete are separate actions
After starting the tunnel, copy its assigned public HTTPS address and open it from another browser or device. Prefer a different network for the final reachability test. Confirm that the page shows only the harmless test workspace you reviewed locally.
If the public result differs from the local page, stop the tunnel before investigating. A target mistake can expose another local HTTP service. Recheck the selected device, local host, and port, then restart only after the configuration is correct.
When testing is complete, use Stop to make the configured tunnel inactive. A stopped tunnel can remain in the dashboard for later use, but its endpoint is not available while it is stopped. Use Delete when you no longer need the configuration at all. Deleting and stopping are not interchangeable: stopping preserves the tunnel record, while deleting removes it.
Creating a tunnel does not start it. Testing requires a running tunnel, a connected selected client, and a running local wmux web process. Stop the tunnel to end the current exposure, or delete it when the saved configuration is no longer needed.
Apply a safety gate before public access
Loopback binding is a local reachability boundary. A Localtonet tunnel intentionally crosses that boundary by providing a public route. The target can remain bound to loopback, but remote users who can reach the tunnel URL may be able to see or use whatever the web page exposes.
If you cannot verify authentication or another effective access restriction, expose only a temporary test workspace containing nonsensitive data. Do not publish private repositories, customer information, production logs, internal infrastructure details, agent prompts, or credentials. An unguessable URL is not an authorization mechanism.
Visible output can be sensitive without terminal control
Build output can reveal dependency versions and internal paths. Git commands can reveal repository remotes, branch names, issue references, or unreleased work. Agent conversations may include proprietary requirements. Errors can reveal usernames, hostnames, directories, internal URLs, and configuration fragments. Confidentiality therefore matters even if a particular release presents a view-only interface.
Do not broaden the bind unnecessarily
When the Localtonet client is on the wmux host, keep wmux on loopback. If the client runs on another computer, that other computer's loopback address refers to itself, not to the wmux host. Making that arrangement work could require a documented wmux network-binding change and additional network controls. The supplied evidence does not establish the exact safe option, so this guide does not guess one.
Review screenshots before publishing them
A current Localtonet configuration screenshot can be useful when it shows the selected device, Process Type, relay selection, local host, local port, and Start control. Before publishing such a screenshot, redact authentication tokens, private assigned details, account information, custom domains that should not be disclosed, and any visible credentials.
Troubleshooting the installation and tunnel
The wmux command is not found
Confirm that the desktop application was installed and launched. On macOS, wmux documents that the CLI installs onto PATH on first launch. Open a new terminal after launching the application because an existing shell may retain the old environment.
On Windows, confirm that WinGet, Chocolatey, or the installer completed successfully. If multiple installation methods were used, determine which copy owns the executable before adding another one. On Linux, inspect the package and release-specific instructions because experimental package behavior may vary.
wmux web does not show an obvious address
Read the entire command output, including messages immediately before an exit. Do not probe random ports. Confirm that the installed version includes the command and consult the current official wmux documentation or command help for release-specific syntax. This tutorial does not invent unsupported flags.
The local browser cannot connect
Confirm that the wmux web process is still running. Enter the exact host, scheme, and port it reported. A stale URL from a previous run may no longer be valid. Resolve this local error before checking the Localtonet client or public URL.
The page loads but shows the wrong workspace
Open wmux locally and verify the intended workspace and panes. Add a harmless identifying line to the test pane. If necessary, restart wmux web, record its current address, and repeat the local test. Confirm that another application is not serving content on the target port.
The local page works but the public page does not
Check each layer in order. Confirm that the Localtonet client is connected, that the selected AuthToken belongs to the wmux computer, and that the HTTP tunnel has been started rather than merely created. Compare the configured local IP address and port with the current wmux web output. Finally, confirm that the web process has not exited.
If Localtonet is running on another computer, remember that a loopback target points back to that other computer. Move the client to the wmux host for the recommended arrangement rather than changing wmux network exposure without verified instructions.
The wrong page appears at the public URL
Stop the tunnel immediately. This usually indicates that the configured port points to another local HTTP service or that the target changed after a restart. Verify the current wmux endpoint locally, correct the target, review its content, and only then start the tunnel again.
The tunnel stopped working after reboot
A reboot stops operating-system processes. Open wmux and inspect the restored workspace. Restart any required agent process and run wmux web again if it did not start through an explicitly configured mechanism. Check whether the emitted port changed. Then verify that the Localtonet client reconnected and start the tunnel if it is currently stopped.
The public page displays sensitive information
Stop the tunnel first. Remove or hide the information locally and determine whether any exposed credential needs to be revoked or rotated. Review which panes and workspaces were visible. Do not resume public access until you have verified both the displayed content and an appropriate access-control strategy.
Windows SmartScreen reports an unknown publisher
The project states that the direct Setup.exe currently uses a SignPath test certificate. Confirm that the installer came from the official wmux site. Prefer the documented WinGet or Chocolatey route when available. Do not disable SmartScreen globally to install one application.
The Linux build behaves differently
Linux support is experimental. Differences may involve the distribution, package format, desktop environment, dependencies, CLI path, or current wmux build. Test the desktop application, CLI, and local web endpoint independently. Do not diagnose an installation or packaging issue as a Localtonet networking issue until the local URL works.
Frequently asked questions
What port does wmux web use?
The current evidence supplied for this guide does not establish a universal port. Run wmux web and use the host and port reported by your installed release.
Is the wmux web interface read-only?
The current primary evidence supplied here confirms loopback binding but does not establish every interaction capability of the current web interface. Test your installed version locally and do not assume that a previous read-only description applies to every release.
Is an unguessable tunnel URL sufficient protection?
No. A difficult-to-guess URL is not authorization. If effective authentication or another verified restriction is unavailable, expose only a temporary workspace containing nonsensitive test data.
Must I change wmux from loopback to a LAN address?
Not when the Localtonet client runs on the same computer. Our client can forward to the loopback host and current wmux port while wmux retains its default local binding.
Which Localtonet Process Type should I choose?
Random Sub Domain is the simplest option for a temporary test. Custom Sub Domain and Custom Domain are available where supported by the current dashboard and plan. All three serve the same selected local content through a public HTTPS address.
Does creating a Localtonet tunnel make it active?
No. Creating the configuration does not start it. Use Start to run the tunnel. The selected client must remain connected, and the local wmux web process must also remain available.
What is the difference between stopping and deleting the tunnel?
Stopping ends the active tunnel while preserving its configuration for later use. Deleting removes the tunnel configuration when you no longer need it.
Does Localtonet require port forwarding or a public IP address?
No. The Localtonet client establishes an outbound connection to a relay server. This standard HTTP tunnel workflow does not require inbound router port forwarding, a public IP address, a VPN, or an inbound firewall change.
Is Localtonet the same as wmux iPhone pairing?
No. This tutorial exposes the wmux browser endpoint through an HTTP tunnel. The official iPhone companion uses wmux's separate Remote pairing workflow with HTTPS over Tailscale and a QR code.
Does wmux require WSL on Windows?
No. wmux uses Windows ConPTY directly. The current documented Windows requirement is an x64 computer running Windows 10 build 1903 or later.
Does wmux support Intel macOS or fully supported Linux installations?
Current project material documents the macOS package for Apple Silicon and describes Linux AppImage, DEB, and RPM builds as experimental. The supplied evidence does not establish an Intel macOS build or full Linux support.
Connect a verified wmux test endpoint with Localtonet
Once wmux web works through its exact loopback address, create an HTTP tunnel with the appropriate Process Type, select the correct device and relay server, enter the verified local host and port, and start it only for a safe test window.
