Set Up Qwen Code Daemon Mode with Localtonet

What daemon mode changes

Qwen Code is an open-source coding agent designed for terminal use. Its developer documentation identifies qwen serve as an HTTP daemon and describes workspace-scoped components, permission mediation, typed events, and client adapters. A daemon makes the agent accessible through a service interface rather than only through the terminal that launched it.

That changes the trust boundary. An interactive tool normally receives instructions from the person at the terminal. A network service must decide which connecting clients may open sessions, submit prompts, receive events, and approve actions. A browser interface is only one client of that service. Protecting its login page alone does not establish that the underlying operations are protected.

With Localtonet, our client establishes an outbound connection to a relay server and provides a public URL for a local HTTP service. In the architecture discussed here, the client and daemon would run on the same host. That is important because 127.0.0.1 always refers to the machine making the connection, not another computer on the network.

Server-Sent Events, or SSE, deliver successive server-to-client events over an open HTTP response. They are not simply a page download. A deployment may successfully serve HTML while failing to deliver incremental events because of authentication, buffering, connection termination, or client incompatibility.

Prerequisites and version provenance

The Qwen Code daemon operator guide is the relevant starting point for startup, authentication, lifecycle, persistence, and logging. The daemon HTTP protocol reference covers routes, request and response shapes, and error codes. These links point to a moving development branch, not an immutable release baseline.

A reproducible deployment needs the executable and documentation to agree. Before attempting a new installation, select a release in the official Qwen Code repository, locate its matching documentation, and record the following information without credentials:

• Exact CLI package version and installation method.
• Operating system, architecture, and required runtime version.
• Documentation tag or commit used for configuration.
• Whether that release includes daemon mode and its supported startup syntax.
• Confirmed listening address and port.
• Model-provider integration and credential storage method.
• Daemon authentication mechanism and authorization test results.
• Client or SDK version, if anything other than the bundled interface is used.

An SDK release number is not sufficient evidence of the daemon version. Likewise, a documentation heading named “Authentication” does not establish a flag, a token format, or which routes enforce it. The important provenance is the exact installed artifact plus the substantive instructions and observed behavior for that artifact.

Use a dedicated, non-administrative account and a disposable project for initial testing. Do not make production repositories, deployment credentials, SSH keys, or unrelated personal files available merely to simplify setup. Ensure that you are authorized to run the service and any future remote-access client on the network.

Installation: what this revision can safely establish

This revision does not provide a verified installation and provider-configuration path. It therefore does not recommend installing a moving latest package or present a minimum Node.js version as universally applicable. npm, Homebrew, and standalone installation recipes are outside this guide’s executable scope until their support is checked against a selected release.

If you already have Qwen Code installed, you can inspect the installation without starting a daemon. On Linux or macOS, the shell can locate the command:

command -v qwen

On Windows Command Prompt:

where qwen

A result proves only that a command is discoverable. It does not establish daemon support, package authenticity, or which provider configuration will be loaded. Multiple results can indicate competing installations. Resolve that ambiguity before starting an agent.

For an existing npm-managed installation, these are package-manager and runtime inspection commands, not Qwen daemon setup commands:

node --version
npm --version
npm list -g @qwen-code/qwen-code --depth=0

Record the reported package version and compare its runtime requirements with its release documentation. An empty package listing may simply mean the executable came from another installer. Do not install a second copy to make the listing appear.

For a fresh setup, stop here until the selected release’s installation and provider instructions are available. A successful package installation alone would not make the rest of the workflow reproducible, and substituting guessed configuration keys would create a misleading tutorial.

Separate provider configuration from daemon access control

There are three different credentials or identities in this architecture. Keeping them separate makes both troubleshooting and security review easier.

A complete provider recipe would need a supported provider, model identifier, endpoint where applicable, credential acquisition method, exact configuration location, and a successful local model request. Those values are not verified for a selected Qwen release here. Do not infer them from another tool’s OpenAI-compatible settings or assume that an interactive login is automatically available to a daemon launched under another account.

Keep credentials outside the repository and outside the agent’s permitted files wherever possible. Use the credential storage mechanism documented for the selected release. Avoid putting secrets in prompt text, URL query strings, screenshots, shared logs, or shell commands saved in history. Do not assume environment variables are invisible to other processes or diagnostic tools.

A working directory is not a sandbox

Changing into a project directory selects a starting context; it does not remove the operating-system account’s access to parent directories, other repositories, network resources, or credentials. A prompt asking the agent to “stay in this folder” is also not an access-control mechanism.

Enforce boundaries through operating-system permissions and, where appropriate, a reviewed isolated environment. Containers and virtual machines require their own configuration review, especially mounted directories, host sockets, network access, and injected secrets. Do not assume that the word “workspace” implies filesystem confinement.

Startup syntax and defaults remain unverified

The earlier workflow used qwen serve --open and http://127.0.0.1:4170. This revision does not certify that flag or address for a particular release. Use the selected release’s operator instructions and inspect the actual listening socket before making a request. Do not broaden the bind address to all interfaces as a workaround for an unexplained connection failure.

Verify an existing local deployment without exposing it

The following checks are useful for an already configured local deployment. They do not supply missing provider or authentication configuration. Keep any tunnel stopped throughout this assessment.

Confirm the listener and its owner

On Linux, inspect listening TCP sockets:

ss -ltnp

On macOS, inspect listening TCP sockets with:

lsof -nP -iTCP -sTCP:LISTEN

On Windows PowerShell:

Get-NetTCPConnection -State Listen |
  Select-Object LocalAddress, LocalPort, OwningProcess

Identify the daemon using its process information and startup output. Process details may be restricted by operating-system permissions. A listener on 127.0.0.1 is IPv4 loopback; ::1 is IPv6 loopback. Wildcard listeners such as 0.0.0.0 or :: are not loopback-only. Review any unexpected listener before continuing.

Check basic HTTP reachability

If, and only if, your release and socket inspection confirm port 4170 on IPv4 loopback, this generic request checks the root response:

curl --noproxy '*' --max-time 5 -i http://127.0.0.1:4170/

The command bypasses configured HTTP proxies for this request and stops waiting after five seconds. A response confirms that an HTTP service answered at that address. It does not prove that the service is Qwen Code, that its provider works, or that its API is secure. A public static page may legitimately return success while protected operations require authentication.

Use a harmless functional prompt only after configuration is verified

For an authenticated local session configured according to matching release instructions, a suitable first prompt is: Reply with LOCAL_CHECK_OK. Do not read or change files, run commands, or use tools. Review the response and any tool or approval activity. This tests a small model interaction without intentionally asking for filesystem access.

The expected functional result is a completed response containing the marker, with no requested tool activity. The prompt itself is not a security boundary. Do not use sensitive files to discover whether permissions are enforced.

Test the actual event subscription

Use the protocol reference for the selected release to identify the authenticated session and event routes. Subscribe before sending the test prompt so that early events are not missed. Observe whether events arrive incrementally and whether the client identifies completion correctly.

No authenticated prompt or SSE command is reproduced here because the credential transport, routes, and request bodies have not been verified together. The local functional checks above are an assessment plan, not a claim that an end-to-end daemon test has passed.

The authentication gate before any public exposure

Read the operator guide’s authentication section together with its deployment threat model for the selected release. The release-specific procedure must explain how to create credentials, how clients present them, which operations require them, and how to revoke them. Without those details, keep the deployment local.

Do not judge protection by the appearance of a login dialog. Test protected operations directly with separate authenticated and unauthenticated clients. An existing browser session may silently supply cookies and make an otherwise invalid test appear to pass.

Use the documented status codes rather than assuming every release returns the same one. For state-changing requests, inspect both the response and resulting state. A rejected-looking response is not sufficient if the operation still happened. For streams, check content, not only whether the connection stayed open.

If any unauthorized request succeeds, stop testing with real project data. Stop any existing tunnel, preserve redacted diagnostic information, correct the configuration, and repeat the entire test matrix. If credentials may have been disclosed, rotate them with their issuing system. Deleting a transcript does not revoke a secret.

Where Localtonet fits, and why setup stops here

For an authenticated HTTP application, our HTTP tunnel is the relevant tunnel family. Our platform can expose a local service without inbound router port forwarding, firewall changes, VPN setup, or a public IP address. This connectivity does not replace the application’s authentication, tool controls, or operating-system permissions.

This guide deliberately does not provide a tunnel-start sequence. A verified Qwen authentication procedure is missing, and the exact current HTTP dashboard sequence has not been established here. Repeating an assumed five-step workflow would imply a completed deployment that this revision cannot substantiate.

For a future validated deployment, follow our HTTP tunnel documentation in its documented order. Keep our client on the same host as the loopback daemon. Select the device-specific token privately, use an available relay from the current dashboard, and configure the local target from the verified listener rather than an assumed default.

HTTP process types include Random Sub Domain, Custom Sub Domain, and Custom Domain. Available options depend on the current product and plan. Custom-domain DNS instructions must come from current documentation. A custom domain does not make an unauthenticated service private.

Remote acceptance criteria for a future validated deployment

Once a release-specific local authentication procedure has passed review, remote verification must repeat the negative tests through the assigned HTTPS address. Use a separate device or clean client without saved cookies. Confirm that missing and invalid credentials cannot create sessions, submit prompts, retrieve protected data, or subscribe to protected streams.

Then test the authorized harmless prompt, incremental event delivery, disconnect behavior, and credential revocation. Do not put real project secrets into the first remote session. Stop the tunnel if any result differs from local behavior. These are acceptance criteria, not instructions to bypass the current stop condition.

Standard HTTP tunneling is not a VPN. Our VPN Manager is a separate private mesh feature. Changing the connectivity architecture does not remove the need to review agent permissions and client access.

Routine operation and troubleshooting

Status and shutdown

Use socket inspection to establish whether a process is listening, then use the release’s documented status mechanism to assess application health. A listening port is not proof of a working provider or a healthy session. This revision does not prescribe unverified Qwen status or shutdown subcommands.

If a public path already exists, stop the Localtonet tunnel first. Next, stop the daemon using the shutdown method documented for its launch mode, whether foreground process, service, or another supervisor. Confirm that its listener disappears. Do not assume that closing a browser stops the daemon or that stopping a parent process has terminated every tool it launched.

Port conflicts

If startup reports that an address is already in use, identify the process owning the socket with the inspection commands above. It may be an older daemon or an unrelated application. Do not kill a process solely because it occupies the expected port.

Stop the intended old instance through its normal lifecycle mechanism, or select another port only through a supported release-specific option. Recheck the listening address after restart. Any future tunnel target must match the confirmed port.

Sessions and persistence

The operator documentation includes persisted sessions and a durability model, but that does not establish exact storage locations or restart guarantees for an unselected release. Do not assume that browser closure ends a session, that a restart deletes history, or that a resumed session safely replays pending work.

Before relying on persistence, use a disposable session to test normal shutdown and restart. Check what conversation state survives, whether permissions must be renewed, and whether unfinished tasks remain active. Treat stored prompts, tool outputs, attachments, and repository excerpts as sensitive data.

Logs and rotation

The operator guide’s daemon log section distinguishes daemon logging from session debug logs and includes external rotation. An exact log path, rotation schedule, or reopen behavior is not verified here. Do not copy a generic rotation rule and assume the daemon will continue writing correctly.

For a chosen release, record the configured log location, ownership, permissions, retention, and rotation method. Verify rotation in a disposable run and ensure logs do not grow without bounds. Redact credentials and project content before sharing diagnostics. Preserve enough timing and error context to distinguish provider failures from transport failures.

Upgrades and optional SDK work

Before upgrading, record the installed artifact and documentation revision, stop remote access, and preserve required session data using the supported procedure. Upgrade through the same installation method and repeat local provider, authentication, prompt, and streaming tests. Do not assume compatibility because a new package starts successfully.

Custom-client development is optional and outside this guide’s implementation scope. The official daemon-client walkthrough and daemon developer documentation are the relevant entry points. Pin compatible client and daemon versions, and test reconnection without automatically replaying state-changing prompts.

Frequently asked questions