Run a shared Qwen Code agent locally, verify it first, then publish its HTTP and SSE service through a controlled Localtonet tunnel
Qwen Code is an open-source coding agent that runs in a terminal and supports interactive, headless, IDE, SDK, channel, and experimental daemon workflows. Its qwen serve command exposes a shared agent session over HTTP and Server-Sent Events using ACP, which makes an HTTP tunnel the relevant Localtonet integration. This guide covers installation, model-provider authentication, local CLI verification, daemon startup, safe endpoint discovery, Localtonet configuration, testing, routine operation, and troubleshooting. Because the supplied Qwen Code documentation does not establish a universal daemon hostname, port, bind address, access-control setting, or client endpoint, we explain how to obtain those values from the running version instead of inventing them.
📋 What's in this guide
How Qwen Code daemon access works
Qwen Code normally runs as an interactive terminal application. You enter a project directory, run qwen, authenticate with a supported model provider, and interact with the agent in the terminal. The project also documents headless execution, IDE integrations, desktop use, SDKs, messaging channels, and an experimental daemon mode.
Daemon mode is started with qwen serve. Qwen Code describes this mode as a shared agent session exposed over HTTP and Server-Sent Events through ACP. HTTP carries requests and related protocol operations, while SSE supports a long-lived server-to-client event stream. This is different from a static website or a conventional JSON-only API because the remote client may need to maintain an open HTTP connection while events arrive.
Localtonet fits after the daemon is working locally. Our client runs on the same device as Qwen Code, or on another device that can reach the daemon over the local network. The client establishes an outbound connection to a Localtonet relay, so the workflow does not require inbound router port forwarding, a public IP address, firewall changes for unsolicited inbound internet traffic, or a separate VPN setup. An HTTP tunnel then maps a public HTTPS address to the Qwen daemon's confirmed local IP address and port.
qwen serve provides the experimental shared-agent service. Its actual listener details must come from the installed version.
Qwen Code explicitly identifies daemon mode as HTTP plus SSE. An HTTP tunnel preserves the application-layer behavior needed for ordinary HTTP requests and event streams. A raw TCP tunnel is not the first choice for this documented workflow unless future Qwen Code documentation specifies a different transport.
There are two separate lifecycles to keep in mind. The Qwen daemon must be running and listening locally, and the Localtonet tunnel must also be started. Creating a tunnel in our dashboard does not start Qwen Code, and starting Qwen Code does not automatically start the tunnel. Remote access works only while the selected Localtonet device is connected, the tunnel is running, and the local daemon remains available.
Prerequisites and decisions to make first
Prepare the host before installing anything. You need a Linux, macOS, or Windows environment covered by one of the documented Qwen Code installation paths, a project directory that the agent may inspect, model-provider credentials appropriate for your chosen provider, and permission to run both Qwen Code and the Localtonet client on the host.
Qwen Code offers several installation methods. The standalone installer is the recommended starting point in its overview. The installer uses a standalone archive when one is available for the platform and may fall back to npm. If it falls back to npm, Node.js 22 or later and npm must already be available on PATH. A direct npm installation always requires Node.js 22 or later. Homebrew is also documented for macOS and Linux.
| Installation path | Documented platforms | Important requirement |
|---|---|---|
| Standalone shell installer | Linux and macOS | May use a standalone archive or fall back to npm; the fallback requires Node.js 22 or later and npm on PATH. |
| Standalone PowerShell installer | Windows | Run from a PowerShell environment permitted to retrieve and execute the official installer. |
| npm | Environments with supported Node.js | Requires Node.js 22 or later and installs the current package globally. |
| Homebrew | macOS and Linux | Requires an existing working Homebrew installation. |
| Offline release archive | Depends on the available release archive | Keep SHA256SUMS next to the archive and pass the archive path to the official installer. |
Choose a safe workspace
Qwen Code is an agentic developer tool, not merely a read-only chat page. Its broader feature set includes file-system and shell-oriented tooling, and the effective behavior depends on its configuration and the approvals you grant. Start it in the intended repository rather than a broad parent directory containing unrelated projects, credentials, personal files, or production configuration.
Use an account with only the permissions the workflow requires. Avoid running the daemon with elevated operating-system privileges unless a documented, reviewed use case genuinely requires them. Before remote access, decide which repository the daemon should serve, which model provider it should use, and which remote clients should be allowed to connect.
Prepare Localtonet without exposing secrets
Install and run the Localtonet client on the Qwen host or on a device that can reach it. The Localtonet device token identifies the client device and is device-specific. Do not place that token in shell examples, source control, screenshots, logs, support messages, or public documentation.
Relay server and region values can vary. Select an available value from the current Localtonet dashboard rather than copying a server code from an old guide. Availability can also vary by plan or deployment, so this article does not hardcode a region or claim that every option is available to every account.
The supplied Qwen Code evidence confirms qwen serve and its HTTP plus SSE transport, but it does not establish a universal hostname, port, bind address, authentication mechanism, or remote-client URL. Do not guess values such as localhost, 0.0.0.0, or a familiar development port. Start the installed daemon, obtain its actual listener details from its startup output or the matching official daemon documentation, and verify its access-control behavior before creating a public tunnel.
Install Qwen Code
Use one installation method only for the initial setup. Running several installers without a reason can leave multiple qwen executables on the machine, making upgrades and troubleshooting harder because the shell may launch a different copy than the one you expect.
Option 1: Recommended installer on Linux or macOS
Run the documented standalone installer:
curl -fsSL https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen-standalone.sh | bash
The installer uses a standalone archive when one is available for the platform. If it falls back to npm, Node.js 22 or later and npm must be available on PATH. Restart the terminal after installation if the qwen command is not immediately available or if the installer changed environment variables.
Option 2: Recommended installer on Windows
Run the documented PowerShell installer:
irm https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen-standalone.ps1 | iex
Close and reopen the terminal after installation if qwen is not found. This allows updated environment variables to take effect. Apply your normal organizational policy for reviewing and running remotely retrieved scripts before execution.
Option 3: Install with npm
If Node.js 22 or later is already installed and available on PATH, install the current Qwen Code package globally:
npm install -g @qwen-code/qwen-code@latest
A global installation should make qwen available to the active user through npm's global executable location. If the installation succeeds but the command cannot be found, reopen the terminal and inspect your Node.js and npm environment before reinstalling.
Option 4: Install with Homebrew
On macOS or Linux with Homebrew already configured, use:
brew install qwen-codeThis path is convenient when Homebrew already manages developer tools on the machine. Keep upgrades consistent with the installation method you selected rather than switching package managers without removing or accounting for the earlier installation.
Offline installation
Qwen Code documentation also describes an offline path using a release archive. Download the archive appropriate to the target environment, keep the release's SHA256SUMS file next to that archive, and run the official installer with --archive PATH, replacing PATH with the actual local archive path. The supplied evidence does not provide a universal archive filename, so do not copy a guessed filename into automation.
--archive PATHConfirm the archive and checksum material correspond to the same release. This is especially important when transferring installation files through an internal mirror or removable media.
Launch, authenticate, and verify Qwen Code locally
Do not begin with daemon mode. First verify that the ordinary interactive CLI launches in the intended project and can connect to a model provider. This separates installation or provider problems from daemon and networking problems.
Enter the intended project
Change to the repository Qwen Code should use. The official quick-start pattern is:
cd your-project
qwen
Replace your-project with the real project directory. Starting from the intended directory matters because it defines the immediate codebase context and reduces the chance of exposing unrelated files to an agent session.
Configure the model provider
On first launch, Qwen Code prompts you to connect a model provider. Its documented menu includes Alibaba ModelStudio options, built-in third-party providers connected with an API key, and a custom-provider path for a local server, proxy, or otherwise unsupported provider. The exact credentials, endpoint fields, account requirements, and model availability depend on the provider you select.
You can also open authentication configuration from an interactive Qwen Code session with:
/authFollow the provider-specific prompts shown by the installed version. Never paste a provider API key into source files, shell history intended for sharing, an article, or a Localtonet tunnel field. Localtonet device tokens and model-provider credentials are separate secrets serving different purposes.
Run a harmless local test
Once authentication is configured, ask a low-risk question that does not require modifying the repository. Qwen Code's overview suggests beginning with:
what does this project do?A successful response establishes that the command launches, the working directory is readable, provider authentication works, and the selected provider can return a result. If this local test fails, resolve it before introducing daemon mode or Localtonet.
A successful interactive request confirms the basic Qwen Code and provider path. It does not prove that qwen serve is listening, that an ACP client can connect, that SSE remains open, or that a Localtonet tunnel is configured correctly. Those are separate checks performed in the next stages.
Start and inspect Qwen Code daemon mode
After the interactive CLI works, leave that session as appropriate for your environment and start the experimental daemon from the intended project context:
cd your-project
qwen serveQwen Code describes this as a shared agent session over HTTP and SSE using ACP, with multiple clients sharing one agent. Because the feature is explicitly experimental, interfaces, configuration, defaults, and client behavior may change between releases. Review the startup output every time you upgrade rather than assuming that an earlier listener configuration still applies.
Record the actual listener information
Before configuring Localtonet, identify four facts from the daemon output and the official daemon documentation matching your installed version:
- The local hostname or IP address on which the daemon listens.
- The local TCP port selected by the daemon.
- The HTTP or ACP path expected by the supported client.
- The daemon's authentication, authorization, session, and origin requirements, if any.
These details are deliberately not filled with sample values here. The supplied evidence does not establish them, and a plausible-looking default could direct the tunnel to the wrong service or expose the daemon with incorrect security assumptions.
Distinguish bind address from connection address
A bind address tells the server which network interfaces accept connections. A client address tells another process where to connect. They are related but not always interchangeable. If Qwen Code reports a loopback-only listener, a Localtonet client on the same machine may be able to target it, while a Localtonet client on another LAN device generally needs an address reachable from that device. Do not broaden the daemon's bind scope merely for convenience without evaluating the resulting LAN exposure.
The safest simple topology is normally to run the Localtonet client on the same host as Qwen Code and target the confirmed local listener. Whether that topology works with a particular daemon bind setting must still be verified from the live process rather than assumed.
Perform a local protocol check
Use a Qwen-supported daemon client or the client integration documented for the installed release. Point it at the exact local URL and path reported by Qwen Code. Confirm that it can establish the HTTP connection, receive SSE events, and interact with the expected session.
A generic browser page is not necessarily a valid test. An ACP daemon may not provide a human-facing page at its root path, and a successful status response does not necessarily prove that the event stream or agent protocol works. Likewise, an HTTP error can show that a listener is reachable even though the selected path or method is wrong. Test with a client that understands the documented protocol.
HTTPS at the Localtonet public address protects the web transport to the tunnel edge, but it does not invent application-level authentication for Qwen Code. If the daemon or its supported client requires credentials, headers, origin checks, session tokens, or another control, preserve and test that control. If the installed daemon provides no access control suitable for internet exposure, do not treat an unguessable URL as authentication. Keep the service local until an appropriate authenticated design is available.
Configure the Localtonet HTTP tunnel
Configure Localtonet only after the Qwen daemon works locally and you have its confirmed local IP address and port. The documented transport is HTTP plus SSE, so create an HTTP tunnel that points to that local target. For current dashboard details, consult our Localtonet HTTP tunnel documentation while following the sequence below.
Install and run the Localtonet client
Run our client on the Qwen Code host or on another device that can reach the confirmed daemon listener. Keep the client connected. Installing the client does not start Qwen Code, so make sure qwen serve is also running.
Authenticate or select the correct device
Use the device-specific token associated with the client that will carry the tunnel, or select that connected device in the dashboard. Never copy a real token into documentation or expose it to a remote Qwen client.
Select an available relay server
Choose a currently available server or region from the dashboard. Do not hardcode an old server code because available values can change and may vary by account, plan, client version, or deployment.
Create an HTTP tunnel to the confirmed local target
Select the HTTP tunnel family and enter the exact local IP address and port reported or configured by the running Qwen daemon. For Process Type, use a generated random subdomain, a selected custom subdomain where supported, or a custom domain as appropriate. These Process Type choices serve the configured content at a public HTTPS address. Check current DNS documentation before using a custom domain because exact DNS requirements are not established in the supplied evidence.
Start the tunnel and copy its assigned public address
Creating the configuration is not enough. Press Start, wait for the tunnel to run, and use the assigned public HTTPS address. Preserve any Qwen-specific ACP path when constructing the remote client URL.
Stop or delete the tunnel when it is no longer needed
Stop the tunnel to end public availability while retaining its configuration, or delete it when the configuration is no longer required. Also manage the Qwen daemon process separately because tunnel and daemon lifecycles are independent.
Construct the remote client URL carefully
The public Localtonet address replaces the local scheme, host, and port used by the remote client. It does not automatically determine the Qwen protocol path. If the supported Qwen client expects a particular ACP or SSE path, append the exact documented path to the assigned public address. Preserve required headers, credentials, protocol versions, and client options.
Do not publish a guessed root URL as though it were the complete daemon endpoint. The fact that the tunnel has a public HTTPS address only proves where the Localtonet edge is reachable. Correct application behavior still depends on routing to the right local listener and using the protocol expected by Qwen Code.
Verify the complete remote path
Test in layers. Layered verification makes failures easier to locate and avoids changing several components at once.
| Layer | What to test | What success establishes |
|---|---|---|
| Interactive CLI | Launch qwen in the project and complete a harmless request. |
The installation, working directory, provider configuration, and basic model connection work. |
| Local daemon | Connect a supported daemon client to the exact local listener and protocol path. | The HTTP and SSE daemon is running and the client understands its ACP behavior. |
| Localtonet tunnel | Confirm the selected Localtonet device is connected and the HTTP tunnel has been started. | The outbound relay path and public address are active. |
| Remote daemon client | Connect from a separate network using the public HTTPS address and the correct Qwen path. | End-to-end HTTP, SSE, application authentication, and agent interaction work remotely. |
| Reconnect behavior | Perform a controlled client reconnect using behavior supported by the installed Qwen version. | The client handles the daemon's session and event-stream lifecycle as expected. |
Test from outside the host's local network
A meaningful remote test should originate from another network, not merely another terminal on the same host. Use a trusted client and the assigned public HTTPS address. Confirm that the client receives events over time, not only that it completes an initial HTTP connection.
If local access works but remote access fails, leave the known-good Qwen configuration unchanged while checking the Localtonet device, tunnel state, local target, public URL, and client path. If neither local nor remote daemon access works, focus on Qwen daemon startup and protocol configuration before changing the tunnel.
Verify project scope and identity
Once connected, use a harmless request to confirm that the remote session is attached to the expected project and agent context. Do not begin with a destructive command. A shared-agent model also means multiple clients may interact with one agent session, so verify which session and workspace a client controls before approving file or shell operations.
Security and routine operation
Publishing an agentic coding service creates a more sensitive exposure than publishing a static status page. A connected agent may have access to source code, configuration, tools, provider credentials, and shell operations according to the local Qwen Code configuration and approval model. Treat the public endpoint as an administrative interface to a development environment.
Plan for two independent processes
Remote availability depends on both Qwen Code and Localtonet. If the daemon stops, the public tunnel can remain active but have no healthy local service to forward to. If the Localtonet client disconnects or the tunnel stops, Qwen Code may continue working locally but cannot be reached through that public address.
For persistent operation, use process-management practices approved for your operating environment, but do not assume undocumented Qwen Code service flags or shutdown behavior. The supplied evidence establishes the startup command but does not define a universal system-service unit, background flag, container deployment, health endpoint, or graceful shutdown command. Build automation only from the documentation matching the installed release.
Keep versions and configuration intentional
Qwen Code is actively developed, and release notes include daemon-related changes. Record the installed version in your operational notes and test upgrades locally before restoring public access. If a package-manager installation follows a moving latest release, do not assume that daemon behavior will remain identical after an upgrade.
Also record the non-secret parts of the deployment: installation method, project directory, provider type, daemon listener configuration, Qwen client type, Localtonet device identity, tunnel type, and the expected application path. Keep credentials and device tokens in their appropriate secret stores rather than in the same notes.
Troubleshooting Qwen Code and Localtonet access
The qwen command is not found
Restart the terminal first, especially after using a standalone installer. If the installer fell back to npm, verify that Node.js 22 or later and npm were available on PATH during installation. If you used direct npm installation, confirm that your shell can find npm's global executable location. Avoid repeatedly installing through multiple package managers until you know which executable path the shell is using.
Qwen launches but cannot complete a request
Open the interactive authentication workflow with /auth and verify the selected provider configuration. Provider account state, API credentials, endpoint settings, and model availability are outside the Localtonet tunnel path. Resolve the interactive CLI first. A tunnel cannot repair invalid provider authentication.
qwen serve is unavailable
Confirm that you are running the intended Qwen Code installation and a release whose documentation includes daemon mode. Multiple installations can cause an older executable to take precedence. Because daemon mode is experimental, use the daemon documentation corresponding to the actual installed version rather than assuming every historical release exposes the same command and configuration.
The daemon starts, but its port is unclear
Do not choose a common development port by trial and error. Read the daemon startup output and the official configuration reference for the installed release. If neither identifies a listener, stop before creating the tunnel and investigate the Qwen Code process locally. The Localtonet local target must be a real IP address and port on or reachable from the client device.
Local daemon access works, but the public address does not
Check that the correct Localtonet device is connected, the HTTP tunnel has been started, and its local target exactly matches the verified daemon listener. Confirm that you are using the currently assigned public address and preserving the required Qwen application path. Creating a tunnel without pressing Start does not make it available.
The public address responds, but the client cannot establish SSE
Recheck the client protocol, endpoint path, authentication material, and expected headers. A response from the public address proves some HTTP reachability but does not prove that the correct SSE endpoint was selected. Compare the remote client configuration with the known-good local client configuration, changing only the base address needed for remote access.
The connection drops during a session
Check all three live components: the remote client, the Qwen daemon, and the Localtonet client and tunnel. Long-lived SSE connections can reveal interruptions that a short request does not. Review Qwen's version-specific session and reconnection behavior before assuming a dropped stream can be resumed transparently.
The tunnel is active, but the daemon is on another device
The Localtonet client must be able to reach the daemon's local IP address and port. A loopback listener on the Qwen host is not reachable from a different LAN device. Either run the Localtonet client on the Qwen host or configure a Qwen listener that is intentionally reachable from the client device, if the official daemon documentation supports that configuration. Expanding the bind address can increase local-network exposure, so evaluate access controls before doing so.
A remote client reaches the wrong workspace
Stop and verify where qwen serve was launched, which daemon process the tunnel targets, and how the client selects a session. Do not approve tool operations until the workspace and session identity are clear. A shared agent can serve multiple clients, which makes explicit session awareness especially important.
Frequently asked questions
What command starts Qwen Code daemon mode?
Run qwen serve from the intended project context. Qwen Code documents this as an experimental shared-agent session over HTTP and SSE using ACP. Authenticate and verify the ordinary qwen CLI before starting daemon mode.
Which port does Qwen Code daemon mode use?
The supplied evidence does not establish a universal port, hostname, or bind address. Obtain the actual listener details from the startup output and official daemon documentation matching your installed Qwen Code version. Do not guess a port when configuring Localtonet.
Should I use a Localtonet HTTP or TCP tunnel?
Use an HTTP tunnel for this documented workflow. Qwen Code identifies qwen serve as HTTP plus SSE, and an HTTP tunnel is the appropriate application-layer mapping for that service. Do not switch to raw TCP unless current Qwen documentation establishes a different requirement.
Does the Localtonet public HTTPS address authenticate Qwen Code users?
No application authentication should be assumed merely because the tunnel provides a public HTTPS address. Preserve and verify whatever authentication, authorization, session, header, or origin controls the installed Qwen daemon and its supported clients require. If suitable daemon access control is unavailable, do not expose the service publicly.
Does Localtonet require router port forwarding or a public IP address?
No. Our client establishes an outbound connection to a Localtonet relay. This lets the tunnel expose the local service without inbound router port forwarding, a public IP address, separate VPN setup, or firewall changes for unsolicited inbound internet connections.
Can the Localtonet client run on a different machine from Qwen Code?
Yes, provided the client device can reach the daemon's confirmed local IP address and port. A daemon bound only to loopback on the Qwen host will not be reachable from another device. Running both processes on the same host often avoids that issue, but the actual Qwen listener must still be verified.
Why must I press Start after creating the tunnel?
Tunnel creation and tunnel operation are separate lifecycle states in Localtonet. A configuration does not become available until it is started. The selected client device must also remain connected, and the Qwen daemon must continue running locally.
Can I use a custom domain for the Qwen daemon tunnel?
HTTP tunnels can use Random Sub Domain, Custom Sub Domain, or Custom Domain Process Types, subject to current availability. Exact custom-domain DNS requirements should be checked in current Localtonet documentation before configuration because they are not established in the supplied evidence.
Connect your verified Qwen Code daemon with Localtonet
Install Qwen Code, authenticate it, confirm the experimental HTTP and SSE daemon locally, and then create a Localtonet HTTP tunnel using the listener values reported by your installed version. Keep the endpoint protected, use least privilege, and stop the tunnel whenever remote agent access is not required.
Get Started Free →
