Run parallel Codex sessions in a browser and reach the terminal grid from outside your local network
MulmoTerminal provides a browser-based terminal grid for supervising multiple coding-agent sessions, including Codex, from one interface. This guide walks through its documented prerequisites, dependency checks, startup options, local verification, routine operation, and common startup problems before adding remote access. Once the application works locally at http://localhost:34567, we will connect that local HTTP service to a public HTTPS address with Localtonet. Because every MulmoTerminal cell is a real PTY and the available evidence does not establish built-in authentication for the main web interface, the security section is essential reading before you expose it.
📋 What's in this guide
How MulmoTerminal and Localtonet fit together
MulmoTerminal is a self-hosted browser application designed for people who run several coding agents in parallel. Instead of opening independent terminal windows and manually checking which process is active, finished, or waiting for permission, it presents the sessions in a grid. Sessions can be marked according to their state, including working, done, idle, and waiting for input. A cockpit-style roster can also retain useful session context while you focus on one terminal.
The important architectural detail is that a terminal cell is not a static dashboard widget. Each cell is a real pseudoterminal, commonly abbreviated as PTY. A shell, Codex, another supported coding-agent CLI, a development server, or a terminal application can run inside a cell. Browser interaction is streamed between the MulmoTerminal server and the browser, so successful remote access requires more than loading the initial HTML page. Keyboard input, live output, terminal resizing, and session state must continue to work.
MulmoTerminal starts locally with one documented npx command and normally opens at http://localhost:34567. The local service remains on the host machine. For remote access, the Localtonet client runs on a device that can reach that address and establishes an outbound connection to one of our relay servers. An HTTP tunnel then connects a public address to the local IP address and port.
This outbound model means that you do not need to configure inbound router port forwarding, obtain a public IP address, change the network firewall to accept unsolicited internet connections, or set up a VPN merely to publish this one HTTP service. The tunnel exists only while the selected Localtonet client is connected and the tunnel is running.
localhost:34567.
PATH, and authenticated using its supported login process.
Do not treat this workflow like publishing a read-only project page. Anyone who can interact with an exposed terminal may be able to run commands with the permissions of the MulmoTerminal host process, inspect accessible files, operate authenticated developer tools, or answer agent prompts. The project evidence used for this guide does not establish built-in authentication or authorization for the main browser interface. Do not share the public address until you have evaluated and implemented an appropriate access-control layer.
Prerequisites for parallel Codex sessions
Prepare the local application completely before creating a tunnel. This separation makes troubleshooting much easier: if the browser terminal does not work on the host itself, changing the tunnel cannot repair the local application.
Required runtime
MulmoTerminal requires Node.js 22.12 or newer. The documented quick-start path uses npx, which retrieves and runs the current published mulmoterminal package. Verify the installed Node.js version before proceeding:
node --versionThe reported version must be at least 22.12. If the command is missing or the version is older, install or update Node.js using an installation method appropriate for your operating system and administration policy. This guide does not prescribe a package-manager command because those commands and package versions vary among operating systems and Node.js distribution methods.
Codex and supporting command-line tools
MulmoTerminal uses Claude Code as its default agent unless another default is selected. For the workflow in this guide, Codex must be installed and discoverable through the same environment in which you start MulmoTerminal. It must also already be logged in. Use the Codex project's current installation and authentication procedure, since those details are controlled by that project and may change independently of MulmoTerminal.
The MulmoTerminal documentation also lists git and gh among the tools expected on PATH. Git supports repository-oriented workflows. The GitHub CLI supports GitHub operations such as pull-request workflows where configured and applicable. Authentication for these tools should be completed locally before you depend on their features inside a browser terminal.
Optional tools
Some tools are useful without being required for the basic launch. In particular, tmux enables session persistence. When it is available, MulmoTerminal can use it so terminal sessions survive events such as a browser reload or server restart and can be reattached later. Without it, do not assume the same persistence behavior.
The project also identifies ffmpeg as useful for video rendering and ollama for local-model workflows. Neither is necessary merely to start MulmoTerminal and run Codex sessions. Install optional dependencies only when you intend to use the features that need them.
| Component | Status for this workflow | Purpose | What to verify |
|---|---|---|---|
| Node.js 22.12 or newer | Required | Runs the MulmoTerminal package | node --version reports a supported release |
| npx | Required by the documented quick start | Retrieves and starts mulmoterminal@latest |
It is available in the environment used to launch the server |
| Codex CLI | Required for Codex sessions | Runs the coding agent inside terminal sessions | It is on PATH and already authenticated |
| git | Expected for repository workflows | Provides repository, branch, diff, and worktree operations | It is on PATH and works in the intended project |
| gh | Expected for GitHub workflows | Supports applicable GitHub and pull-request operations | It is on PATH and authenticated if those operations are needed |
| tmux | Optional but useful | Provides persistent, reattachable sessions | Install it before relying on persistence across restarts |
| Localtonet client | Required only for remote access | Establishes the outbound connection for the HTTP tunnel | Run it on the host or another device that can reach MulmoTerminal |
A command that works in one shell is not automatically visible to a process launched by another account, service manager, desktop launcher, or restricted environment. Start MulmoTerminal from an environment whose PATH includes Codex and the supporting tools you expect it to use.
Install and start MulmoTerminal
The documented installation path is intentionally lightweight. You do not need to clone the source repository for normal use, and you do not need to create a global npm installation. The current package can be checked and launched through npx.
Confirm the Node.js requirement
Run node --version in the terminal that will launch MulmoTerminal. Continue only when it reports Node.js 22.12 or newer.
Run the dependency check
Run npx mulmoterminal@latest init. The documented init command reports dependencies that MulmoTerminal cannot find. Address missing required tools before continuing, and decide whether optional tools such as tmux are needed for your workflow.
Start MulmoTerminal with Codex selected
Launch the current package with the documented --agent codex option. Selecting Codex explicitly avoids starting with the default Claude Code agent.
Open the local browser interface
The application starts at http://localhost:34567 and is documented to open the browser. If a browser does not open automatically, enter that local address manually on the host.
First run the dependency report:
npx mulmoterminal@latest initThen start MulmoTerminal with Codex as the selected agent:
npx mulmoterminal@latest --agent codex
Leave this terminal process running. Closing it can stop the MulmoTerminal server even if individual sessions have persistence through tmux. Persistence of a terminal session and availability of the browser application are related but separate concerns: the server must be running for a browser to reconnect to and control the session.
npx runs the current published package
The @latest selector requests the latest published release at execution time. A later launch may therefore retrieve a newer release with changed behavior. For operational use, review updates before introducing them on a host that controls important repositories or authenticated developer tools.
Configure the working directory, agent, and port
The simplest startup command uses the shell's current working context and the default port. MulmoTerminal also documents options for choosing the project directory, selecting Codex as the agent, and changing the listening port.
Start in a specific project directory
Use --cwd when you want MulmoTerminal to start with a specific project directory. Replace the example path with the path to your own project:
npx mulmoterminal@latest --agent codex --cwd ./my-projectBefore launching, confirm that the account running MulmoTerminal is supposed to have access to this directory. The coding agent and any shells opened in the interface operate with the host process's effective permissions. A narrowly scoped project directory reduces accidental navigation, but it should not be treated as a security sandbox.
Choose a different local port
Port 34567 is the documented default. If another process already uses it, MulmoTerminal supports --port. For example, the following starts the application on port 34568:
npx mulmoterminal@latest --agent codex --port 34568
When changing the port, update every later reference consistently. Local verification would use http://localhost:34568, and the Localtonet HTTP tunnel would target port 34568 rather than 34567.
Choose Codex as the persistent default
MulmoTerminal supports a defaultAgent setting in ~/.mulmoterminal/config.json. The available evidence establishes the setting name and location, but this guide does not reproduce a complete configuration file because a full authoritative schema was not provided. If you manage that file, preserve its existing structure and use the project's current configuration guidance rather than replacing it with an assumed minimal document.
The command-line option is the safest self-contained choice for this tutorial:
npx mulmoterminal@latest --agent codex --cwd ./my-project
MulmoTerminal checks the selected default agent at startup. If Codex cannot be found, return to the init dependency report and verify the launch environment's PATH. Do not solve a path problem by placing credentials or tokens directly in a command line, configuration example, or tunnel field.
Verify MulmoTerminal locally before tunneling it
A successful launch message is only the first check. Because this is an interactive terminal application, verify the full browser workflow from the host before adding a public network path.
Check the HTTP endpoint
Open http://localhost:34567 in a browser on the MulmoTerminal host. If you selected a custom port, use that port instead. The interface should load without a connection error. A blank page, endless loading state, or immediate disconnect indicates a local application issue that should be resolved before configuring Localtonet.
Open and interact with a terminal
Create or select a terminal cell using the application's interface. Confirm that terminal output appears, keyboard input is accepted, and ordinary terminal interaction works. The objective is not to run a risky test command. It is to prove that the browser is attached to a functioning PTY.
Confirm Codex can start
Start a Codex session through the MulmoTerminal workflow. Verify that it does not fail because the executable is missing or because authentication has not been completed. If Codex prompts for setup that should have been completed locally, stop and finish that setup through the supported Codex process rather than attempting to expose an incomplete environment.
Test state updates
One of MulmoTerminal's main benefits is its ability to show which agents are working, done, or waiting for input. Exercise a harmless task and confirm that the visible state changes as the session progresses. If multiple sessions are part of your intended workflow, create a small test set and make sure the grid remains understandable.
Test a browser reload
Reload the page and observe whether the interface reconnects as expected. If you installed and enabled tmux, confirm that the session persistence you need actually works in your environment. Do not assume persistence merely because the package detected tmux. A deliberate local test is safer than discovering a session-loss problem during remote work.
| Local test | Expected result | If it fails |
|---|---|---|
| Open the local URL | The terminal grid loads from localhost:34567 |
Check the server process, startup output, and selected port |
| Interact with a terminal | Input, output, and terminal updates work | Treat this as a local application issue, not a tunnel issue |
| Start Codex | The Codex process launches in the selected project context | Verify installation, PATH, and local authentication |
| Observe session state | The grid reflects working, waiting, or completed activity | Review the session and local application output |
| Reload the browser | The interface reconnects; persistent sessions survive when properly backed by tmux |
Verify tmux availability and your persistence expectations |
A tunnel adds another network path, but it does not correct missing dependencies, failed agent authentication, a conflicting port, broken PTY interaction, or a stopped MulmoTerminal process. Establish a reliable local baseline first.
Operate parallel sessions without losing context
MulmoTerminal is designed for supervision rather than merely placing several terminals on one page. Each session can report its status to the grid, making it easier to identify which agent is working and which one is waiting for a decision. A session that needs input can be highlighted, while completed work can be distinguished from work that is still running.
When you focus on one agent, the cockpit roster can retain a one-line view of the other sessions. Depending on the activity available for a session, that view can include context such as an AI summary, the most recent prompt, the latest reply, and pull-request phase information. This reduces the need to inspect every terminal manually just to remember what each agent is doing.
Use separate worktrees for parallel agent work
MulmoTerminal supports Git worktree-oriented isolation for parallel repository tasks. This matters because two coding agents modifying the same checkout can overwrite files, contend for generated output, or make branch state difficult to reason about. Separate worktrees provide distinct working directories while remaining connected to the same Git repository.
The project applies a one-agent-session-per-worktree limitation to agent sessions. Other terminal processes, such as a shell or development-server launcher, can still operate in the same worktree. Use that flexibility carefully. A development server and an agent may reasonably share a worktree, but two independent agents editing the same files should be isolated unless you intentionally manage their coordination.
Understand persistence boundaries
With tmux available, sessions can survive a browser reload, a MulmoTerminal server restart, or a temporary browser disconnection. This does not mean every part of the stack is permanently available. The MulmoTerminal web server must be running for browser access, the Localtonet client must be connected for remote access, and the specific tunnel must be started.
These layers have separate lifecycles. A persistent Codex process can remain alive while the browser interface is temporarily unavailable. Similarly, MulmoTerminal can continue working locally while its Localtonet tunnel is stopped. Understanding these boundaries helps you choose the correct recovery action.
Stop remote access independently
When remote access is no longer required, stop the Localtonet tunnel. This removes the public route without requiring you to terminate MulmoTerminal or its local sessions. If you are finished with the work entirely, stop the local application and review any remaining tmux sessions so that unattended agent processes are not left running accidentally.
Expose the working MulmoTerminal service with Localtonet
Configure Localtonet only after the local interface works at the intended address. For the documented default, the target is the local HTTP service on port 34567. Run our client on the MulmoTerminal host when possible. It can also run on another device that can reach the service, but then 127.0.0.1 would refer to that other device rather than the MulmoTerminal host.
An HTTP tunnel is the appropriate family for a browser application. MulmoTerminal also uses interactive browser traffic for its terminal stream, so verification must include live input and output after tunneling. Do not consider the integration complete merely because the first page renders.
Install and run the Localtonet client
Install our client for the operating system used by the device that can reach MulmoTerminal. Keep the client running so it can establish the outbound relay connection. Use the current installation path presented by our platform rather than an unverified command copied from another environment.
Authenticate or select the client device
Use the device-specific authentication token associated with the client that will run the tunnel. Treat this token as a secret. Do not place it in documentation, screenshots, shell history, public repositories, or messages.
Select an available relay server
Choose a currently available Localtonet relay server or region from the dashboard. Available server codes and regions can vary, so obtain the value from the current product instead of copying a hardcoded example.
Create an HTTP tunnel to MulmoTerminal
Create an HTTP tunnel and set its local target to the IP address and port where MulmoTerminal is reachable. When our client runs on the same host and MulmoTerminal uses its default port, use the loopback target 127.0.0.1 with port 34567. If you changed the port, enter that selected port instead.
Start the tunnel
Creating a tunnel does not start it. Use the Start button after reviewing the target and exposure decision. The tunnel then provides its assigned public address while the selected client remains connected and the tunnel remains running.
Verify the public address and interactive terminal
Open the assigned public address from a separate browser or network. Confirm that the grid loads, a terminal attaches, output continues to update, keyboard input works, and reconnect behavior is acceptable. Stop the tunnel if any unexpected exposure or access behavior appears.
HTTP and File Server tunnels can use a generated random subdomain, a supported selected subdomain, or a custom domain. For a first verification, a generated address avoids introducing custom DNS configuration into the troubleshooting path. If you later need a custom domain, check the current requirements in our documentation before changing DNS records.
The exact dashboard choices, available relay servers, and plan-dependent options can change. We therefore do not hardcode a relay code or claim that every domain option, region, or control is included with every subscription. For the current product flow, consult the Localtonet HTTP tunnel documentation while keeping the local target established in this guide.
Loading the MulmoTerminal interface proves that the initial HTTP path works. It does not by itself prove that the browser terminal stream works correctly. Open a session, type a harmless command, observe live output, test terminal resizing if relevant, and reload the browser before relying on the remote workflow.
Secure remote browser-terminal access
Remote terminal access deserves a stricter risk assessment than an ordinary development preview. The browser interface may expose terminals connected to source repositories, authenticated CLIs, build systems, environment variables, local files, and agent approval prompts. The effective impact depends on the permissions of the account running MulmoTerminal and the tools available to that account.
Do not rely on an unguessable URL as authentication
A generated public address should not be treated as an authorization mechanism. The evidence available for this article does not establish built-in authentication for MulmoTerminal's main web interface, and it does not justify claiming that a particular Localtonet access-control option is universally available on every plan or configuration.
Before exposure, place a verified authentication and authorization layer in front of the application, or limit the workflow to an environment where access is otherwise strongly controlled. If you evaluate dashboard-level restrictions, confirm their current availability and behavior in your own Localtonet account. Do not assume a control exists merely because another tunneling platform offers something similar.
Use a dedicated, least-privileged host account
Run MulmoTerminal as an account with only the repository and tools needed for the intended task. Avoid using a broadly privileged administrator account. Review readable SSH material, cloud credentials, package registries, environment files, browser-accessible secrets, and authenticated command-line sessions.
Least privilege does not remove all risk, but it limits the damage if the browser terminal is accessed unexpectedly or if an agent performs an unintended action. Repository-specific credentials and narrowly scoped tokens are preferable to credentials that can administer an entire organization.
Keep the local target on loopback when possible
If our client and MulmoTerminal run on the same host, targeting 127.0.0.1 avoids requiring MulmoTerminal to listen broadly on the local network. Do not change the application to listen on every interface merely to make tunneling easier unless you understand and accept the resulting LAN exposure.
If the Localtonet client runs on another device, MulmoTerminal must be reachable from that device through an appropriate local address. That design expands the local network attack surface and should be reviewed separately from the public tunnel.
Expose the service only while needed
Start the tunnel shortly before remote use and stop it when the task is complete. Localtonet separates tunnel creation from tunnel runtime, so a saved configuration can remain in the dashboard while the public route is stopped. Delete configurations that are no longer needed.
Protect device tokens and developer credentials
A Localtonet authentication token identifies the client device and must remain private. Codex credentials, GitHub authentication, SSH keys, package registry credentials, and cloud tokens require the same care. Never paste them into a public terminal transcript, article, screenshot, issue, or shared chat.
Review unattended behavior
Parallel coding agents can continue working after you move away from the screen. Review approval behavior, repository boundaries, generated commands, and tools available to each session. A remote browser should not become a reason to weaken normal code review, command approval, or change-management practices.
127.0.0.1 when our client runs on the same machine.
If you cannot verify an effective authentication and authorization layer for the browser terminal, do not leave the tunnel publicly accessible. Test with non-sensitive repositories and restricted credentials first, then obtain a security review appropriate to the value of the host and its data.
Troubleshoot installation, startup, and remote access
Node.js is missing or too old
Run node --version. If the command is missing, install Node.js. If the version is below 22.12, update it. After changing Node.js installations, open a new terminal and check the version again so that an older executable earlier on PATH does not remain active.
The dependency check cannot find Codex
Run the documented diagnostic again:
npx mulmoterminal@latest init
If Codex is installed but still reported as missing, compare the environment used for installation with the environment used to launch MulmoTerminal. A shell profile may add directories to PATH only for interactive shells. Do not guess a binary path or set an undocumented environment variable. Correct the launch environment using the supported installation details for Codex.
MulmoTerminal starts with the wrong agent
Claude Code is the default unless another agent is selected. Start with the explicit option:
npx mulmoterminal@latest --agent codex
If you manage a persistent default, review the defaultAgent value in ~/.mulmoterminal/config.json using the current project configuration guidance. Avoid replacing an existing file with an incomplete guessed configuration.
Port 34567 is already in use
Stop the conflicting process if it is unnecessary, or select another port with the documented option:
npx mulmoterminal@latest --agent codex --port 34568Open the matching local URL and update the Localtonet tunnel target to the same port. A mismatch between the application port and tunnel target commonly produces a failed connection even though both services are otherwise healthy.
Startup fails with ERR_MODULE_NOT_FOUND
An interrupted first npx installation can leave a partially unpacked directory under ~/.npm/_npx/<hash>. A later startup may then fail with ERR_MODULE_NOT_FOUND. MulmoTerminal's launcher detects this condition and prints the exact removal command for the affected cache entry.
Run the specific removal command printed by the launcher, review it before execution, and then retry:
npx mulmoterminal@latestDo not delete an arbitrary path based on a copied hash. Use the path reported for your own failed installation.
The local page does not load
Confirm that the MulmoTerminal process is still running and inspect its terminal output. Verify whether you selected a custom port. Test the exact local address on the host. If the application stopped, restart it before examining Localtonet.
The Localtonet public address does not load
Check the layers in order:
- MulmoTerminal is running.
- The local URL works on the host.
- The Localtonet client is connected.
- The correct device token is associated with the tunnel.
- The HTTP tunnel targets the correct local IP address and port.
- The tunnel has been started, not merely created.
If our client is on another machine, do not use 127.0.0.1 unless MulmoTerminal also runs on that machine. From the client's perspective, loopback always means the client machine itself.
The page loads but the terminal does not respond
First repeat the same interaction locally. If the local terminal is also unresponsive, investigate MulmoTerminal, its PTY session, and the selected agent. If local interaction works but remote interaction does not, verify the current HTTP tunnel behavior for the application's interactive browser connection. Record whether output, input, reconnects, or only specific actions fail. That distinction is more useful than reporting that the site is simply broken.
The supplied product context establishes Localtonet HTTP tunneling, but it does not provide a version-specific compatibility guarantee for every MulmoTerminal release or every interactive transport behavior. Validate the exact client and application versions you intend to use.
Sessions disappear after a restart
Verify that tmux is installed and available to the same account that launches MulmoTerminal. The project describes tmux as the mechanism for session persistence. If it is absent, do not expect terminal processes to survive the same restart and reconnect scenarios.
Also distinguish a persistent session from a reachable web interface. A session may remain alive in tmux while MulmoTerminal or its tunnel is temporarily stopped. Restart the correct layer rather than creating duplicate agent sessions.
The tunnel worked and then became unavailable
A Localtonet tunnel is available only while the selected client is connected and the tunnel is running. Check whether the host slept, lost network connectivity, stopped our client, or stopped the tunnel. Also confirm that MulmoTerminal itself is still listening on the configured port.
Frequently asked questions
What command installs and starts MulmoTerminal?
The documented quick start is npx mulmoterminal@latest. For this Codex-focused workflow, use npx mulmoterminal@latest --agent codex. Node.js 22.12 or newer is required.
How can I check for missing MulmoTerminal dependencies?
Run npx mulmoterminal@latest init. It reports dependencies that the application cannot find. For Codex sessions, make sure Codex is installed, on PATH, and already authenticated.
What local port does MulmoTerminal use?
The documented default address is http://localhost:34567. You can select another port with --port. If you change it, use the same port in the browser and the Localtonet tunnel target.
Which Localtonet tunnel type should I use for MulmoTerminal?
Use an HTTP tunnel because MulmoTerminal provides a browser application through a local HTTP endpoint. After setup, verify the live terminal interaction as well as the initial page load.
Should the Localtonet target be localhost or 127.0.0.1?
When our client runs on the same host as MulmoTerminal, use the loopback IP 127.0.0.1 and the configured port, normally 34567. If our client runs on another device, loopback points to that other device, so you must use an address through which it can actually reach the MulmoTerminal host.
Does MulmoTerminal provide built-in authentication for the main browser terminal?
The evidence available for this guide does not establish built-in authentication or authorization for the main web interface. Treat the interface as sensitive and do not expose it publicly without a verified access-control design.
Does Localtonet need router port forwarding or a public IP address?
No. Our client establishes an outbound connection to a Localtonet relay. You do not need inbound router port forwarding, firewall changes for unsolicited inbound traffic, VPN setup, or a public IP address for this tunnel workflow.
Will sessions survive if the browser or server restarts?
MulmoTerminal uses tmux, when available, for persistence across reloads, reconnects, and server restarts. Install it and test the behavior locally before relying on persistence. The web server and Localtonet tunnel still need to be running for remote browser access.
Can I stop remote access without stopping my Codex sessions?
Yes. Stop the Localtonet tunnel to remove its public route while leaving the local MulmoTerminal application running. Whether individual sessions continue through later application restarts depends on your local persistence setup, including tmux.
Connect your verified MulmoTerminal service with Localtonet
Once MulmoTerminal and Codex work reliably on the local host, create an HTTP tunnel to the verified local port, add appropriate access controls, test the complete interactive terminal workflow, and stop the tunnel whenever remote access is no longer needed.
Get Started Free →
