Get

Windows command line

The AirCode Ø Windows setup installs an aircode command for PowerShell and Command Prompt. It uses the Node.js runtime and ConPTY support already embedded in the desktop application; WSL and a system Node.js installation are not required.

Open a new terminal after installing or updating AirCode Ø so it receives the updated user PATH, then verify the command:

aircode version
aircode serve --help

The installer resolves the command relative to its own installation directory, so choosing a custom directory in setup is supported.

Desktop executable or server command?

If you want to… Use
Connect an Electron window to a local or remote server Open the AirCode Ø desktop app
Run the embedded local server and use it from Electron Open the desktop app and choose Run on this machine
Run a server without an Electron window Open a terminal and run aircode serve

The desktop executable is not a supported --serve entry point: it always opens Electron. The aircode command uses the runtime and server payload installed with the desktop app, but starts a separate foreground process. See Desktop operating modes for the complete lifecycle summary.

Start a server

serve is the default command, so these forms are equivalent:

aircode serve --projects-root "D:\Projects"
aircode --projects-root "D:\Projects"

The server runs in the foreground and writes logs to that terminal. Press Ctrl+C to stop it cleanly. Each projects root gets its own isolated runtime state and session namespace. When the preferred port is already used by another root, AirCode Ø selects the next available port automatically.

Serve options

Option Default Purpose and equivalent setting
--projects-root <dir> current directory Root whose subfolders AirCode Ø presents as projects. The directory must already exist. Env: AIRCODE_PROJECTS_ROOT; JSON: projectsRoot
--host <address> Tailscale IP, otherwise 127.0.0.1 Network interface on which the HTTP server listens. Env: AIRCODE_HOST; JSON: host
--port <number> 7860 HTTP port from 1 to 65535. An explicit busy port fails instead of silently changing. Env: AIRCODE_PORT; JSON: port
--public-url <url> none Public HTTP(S) base URL used in links and notifications. Env: AIRCODE_PUBLIC_URL; JSON: publicUrl
--config <file> user config file Alternate JSON configuration file. Env: AIRCODE_CONFIG
--state-dir <dir> user state directory Alternate runtime-state directory. Env: AIRCODE_STATE_DIR
--password <value> generated or configured Access password for this process. Convenient but visible in shell history and potentially process inspection. Env: AIRCODE_AUTH_PASSWORD; JSON: authPassword
--password-file <file> none Read the access password from a private file
--no-password off Disable authentication explicitly; use only on an intentionally trusted interface
-h, --help Show command help without starting the server

The standard Windows config file is %USERPROFILE%\.config\aircode\config.json; runtime state defaults to root-specific directories beneath %USERPROFILE%\.local\state\aircode\instances.

Paths containing spaces must be quoted. Both --option value and --option=value are accepted. Command-line options take precedence over environment variables, which take precedence over config.json, then defaults.

On first run AirCode Ø generates a password, stores it in the selected configuration file, and prints it once. --password is available when complete command-line provisioning is required, but its value can be exposed through process inspection and shell history. Prefer --password-file, a protected config file, or a securely supplied AIRCODE_AUTH_PASSWORD. Disabling auth must be explicit with --no-password.

Examples

Multiple roots at the same time

Open one terminal in the first root:

cd "$HOME\Desktop"
aircode

Then open another terminal in a different root:

cd "$HOME\Documents"
aircode

If Tailscale assigned 100.84.12.30 to the computer, the two banners can report http://100.84.12.30:7860 and http://100.84.12.30:7861. The instances do not share runtime state or sessions. Running aircode again from a root that is already active reports its existing URL instead of starting a duplicate.

Local machine only

aircode serve `
  --projects-root "D:\Projects" `
  --host 127.0.0.1 `
  --port 7860

Open http://127.0.0.1:7860.

Tailscale or a private VPN

Bind the exact VPN address assigned to the Windows machine:

aircode serve `
  --projects-root "D:\Projects" `
  --host 100.84.12.30 `
  --port 7860

Other devices on the same private network can then open http://100.84.12.30:7860. Prefer an exact VPN address over 0.0.0.0.

Local network

aircode serve `
  --projects-root "D:\Projects" `
  --host 192.168.1.25 `
  --port 7860

Windows Firewall may ask whether to allow the connection. Only allow the network profiles you intend to use.

Reverse proxy or tunnel URL

aircode serve `
  --projects-root "D:\Projects" `
  --host 127.0.0.1 `
  --port 7860 `
  --public-url "https://aircode.example.com"

--public-url only tells AirCode Ø which address to place in generated links. It does not open a firewall port, start a reverse proxy, or create a tunnel. Use Remote access for the built-in outbound tunnel, Tailscale, or private-network guidance.

Separate configuration and state

aircode serve `
  --projects-root "D:\Projects" `
  --config "D:\AirCodeData\config.json" `
  --state-dir "D:\AirCodeData\state"

If another terminal needs to run a lifecycle command against this instance, set the same state directory first:

$env:AIRCODE_STATE_DIR = "D:\AirCodeData\state"
aircode status
aircode stop

Desktop app coexistence

The foreground CLI server and the local server managed by the desktop window are separate processes. aircode status and aircode stop only target the foreground CLI server; they do not report or control the desktop-managed server. Before reusing the same host and port, quit AirCode Ø from its notification-area icon, not only by closing its window. Alternatively, give the CLI server another port.

Starting from a terminal exposes the AirCode Ø web application and its authenticated API. It does not turn the projects directory into a public file share: file access remains scoped to projects beneath projectsRoot and is enforced by the server.

Additional settings

Agent executable paths, session limits, browser controls, knowledge, orchestration, notifications, and token optimization remain available through environment variables and config.json. See Configuration for the complete configuration precedence and common settings.