LAN Editor

On Android, the LAN editor exposes the script workspace to a browser on the same local network.

Connect

1. Open Settings → LAN Editor and choose Start.
2. Enter the displayed URL on the other computer.
3. Enter the short pairing PIN shown by the app.

On Android 17 and later, Android asks the first time whether the app may use your local network. The editor needs it: without it, no browser can reach the phone. If you have already allowed Nearby devices, Android does not ask again.

The port is fixed at 8765.

Which networks to use

The editor is meant for a network you control: your home Wi-Fi, a lab bench, or a hotspot from your own phone. The PIN decides who can pair, but the connection itself is not encrypted, so anyone else on the same network could read the PIN, your scripts, and what the running peripheral is doing.

Avoid public Wi-Fi, guest networks, and shared office networks. The app recognises two kinds of public network and asks before starting the editor on either:

• Wi-Fi without a password, which anyone in range can join.
• Wi-Fi with a sign-in page, like a café, hotel, or airport network.

The app cannot recognise every shared network. A password-protected office network looks the same as your home Wi-Fi, so it is still your call where you start the editor. When you are not sure, use your phone’s hotspot.

Choose Restart with new PIN to invalidate the current browser session. Stop the server when you no longer need it.

More than one editor at a time

Several browsers can pair with the same PIN, and they all share one script library and one running peripheral: a deploy or a stop from any of them affects the device itself.

Settings → LAN Editor lists the editors connected right now, what each has open, and offers Disconnect for one of them without ending anyone else’s session. Closing a browser ends its own session within a few seconds; one that stops responding without closing — a laptop that sleeps, say — ends after five minutes. Either way, reopening the address and entering the PIN starts a new session.

Two tabs of the same browser share one session, because the pairing is remembered per browser rather than per tab. Two different browsers, or two devices, are two sessions.

If two people edit the same script, whoever saves second is told that it changed, and chooses between reloading what is stored and overwriting it. Nothing is overwritten silently. The same applies when the script is edited on the phone and in a browser at once.

Scripts made of several files

A script starts as one file. When it outgrows that, Split into files — in the script’s row in the library list, or Code ▸ Split into Files… on the desktop app — turns it into a set of files with one entry file that runs first.

The editor asks before it splits, and shows what would change meaning first: mainly that a top-level var or function stops being visible outside its own file. Splitting is permanent — deleting files afterwards does not undo it — so the confirmation is worth reading rather than clicking through.

Once split, a strip above the editor lists the files:

• Click a name to switch files. Unsaved work in the file you leave is kept, so moving around inside a script never prompts and never loses anything.
• + adds a file. Names are plain and flat: codec.js, not ./codec.js or lib/codec.js.
• Remove deletes the file you are viewing. Make entry changes which file runs first, which also moves where the script’s header comment is read from.
• A dot on a name means that file has unsaved changes. Save writes every changed file at once.

Deploy always runs what is stored, so it saves first. If that save cannot be written, the run is cancelled rather than quietly running the previous version.

Splitting appears once it is enabled for your build; until then a script that is already split still opens and can be read, but not edited or run.

See Real-time Authoring for deployment behavior and session semantics.