# Lunel: a phone-first IDE that runs the real toolchain on your machine

> An Expo app, a Node CLI, two Bun servers and a Rust PTY binary, assembled so a phone can edit files, run git and open a terminal on a remote computer. Useful, opinionated, and clearly pre-1.0.

**lunel-dev/lunel** — ai powered mobile ide and cloud development platform

- Repository: https://github.com/lunel-dev/lunel
- Website: https://lunel.dev
- Stars: 1,100 · Forks: 125
- Language: TypeScript
- License: MIT
- Published: 2026-10-07 · Updated: 2026-10-07 · Language: en
- Canonical page: https://hysenlabs.com/projects/lunel-dev-lunel

## A phone app that deliberately holds no logic

The most consequential design decision is stated plainly in the README: the app is a dumb client, with most logic in the CLI, and the app acts as a rendering client. That single choice determines everything else about the project. It means the phone does not need to understand your repository, interpret git output or emulate a shell. It draws what the CLI tells it to draw.

The app is built with Expo for iOS, Android and web from one codebase, and it offers a file explorer and editor, git integration, a terminal emulator, and process management. That list is complete rather than aspirational, which is unusual in a project at this stage.

It also ships 22 interface languages, including a few that overlap in a way that suggests the list grew organically rather than being curated: `en`, `zh`, `ja`, `ko`, `es`, `pt`, `de`, `fr`, `vi`, `ru`, `id`, `pl`, `tr`, `it`, `nl`, `sv`, `uk`, `fi`, `zh-TW`, `tw`, `ms` and `es-MX`. Having both `zh-TW` and `tw` is a small sign of what to expect from the polish level elsewhere.

The project is MIT licensed, hosted at lunel.dev, and the last push was on 2026-05-14.

## The CLI is where the machine actually happens

The CLI is a Node.js program that bridges your local machine to the app over a WebSocket. The README is upfront about its responsibilities: filesystem operations such as read, write and grep, git commands including status, commit, push and pull, terminal spawning, process management, port scanning, and system monitoring for CPU, memory, disk and battery.

That list is the real feature set. A phone app that can grep a codebase, commit and push is already more useful than most remote coding setups, and the battery and CPU monitoring suggests the author expected this to be used for long sessions away from a desk. Port scanning also implies you can forward to something, though the README does not spell out how.

Running it is one command, with no global install step:

```bash
npx lunel-cli
```

The `cli/` directory holds it, in Node and TypeScript, and the Makefile exposes the usual three targets for that directory: an install step running `npm install`, a build step running `tsc compile`, and a dev target that builds and runs.

## Two Bun servers and a session code between them

Pairing works through a manager server and a proxy server, both written in Bun. The manager is described as a session control plane and the proxy as a WebSocket relay, and the README says they connect the CLI and the app using session codes. A public version is deployed at gateway.lunel.dev.

Three details here are worth attention. Sessions have a ten-minute time to live, so a phone pairing expires if you walk away from the task, which is a reasonable default for something that hands a phone the keys to a developer machine. Pairing is by QR code, which avoids typing a long code into a phone keyboard. And the architecture is dual-channel, separating control messages from data, so terminal output and file contents do not contend with commands on one socket.

The Makefile splits the two servers into separate target groups, `manager-install`, `manager-dev` and `manager-start` for the control plane, and `proxy-install`, `proxy-dev` and `proxy-start` for the relay. Both use `bun install`, and both dev targets pass `--watch`. The duplication is not elegant, but it does let the two services be run and debugged independently.

## A Rust PTY that renders a screen buffer as a cell grid

The part of this project most likely to be reused elsewhere is the `pty/` directory: a Rust binary for pseudo-terminal management, used by the CLI. It is not a wrapper around an existing crate. The README says it uses the internal libraries of a wezterm fork hosted at github.com/sohzm/wezterm, which is why a terminal screen can be treated as a grid.

The mechanism is worth understanding because it explains the whole design. The screen buffer is a cell grid where each cell carries a character plus foreground and background colour, which is exactly the data a mobile rendering client needs to draw a terminal. The output runs a 24fps render loop, and the README is specific that updates are sent only when content changes. Over a phone connection, that difference is the difference between a terminal you can use and one that drains your battery.

The wire format is a JSON line protocol over stdin and stdout, which keeps the boundary between the Rust binary and the Node CLI simple and inspectable. The Makefile builds it with `cargo build --release` for `pty-build` and `cargo build` for `pty-dev`.

## Two advertised halves, one of which does not exist yet

The README describes two ways to use the project and is candid that one is unfinished. Lunel Connect is the one that works: remotely using a PC without dealing with SSH, geared towards coding. Lunel Cloud is listed as coming soon, and the title of the project calls it a cloud development platform.

The repository is less consistent about the same gap. The Makefile's help text mentions targets for a component called sandman across several places, including an install description that reads as covering app, cli, gateway and sandman, yet the directory listing at the top of the repository has no `sandman/` entry at all. The help output itself flags the component as not yet added. So the cloud half appears in the build system's vocabulary, in the README's feature list, and in the product name, while the code is absent from the tree. Whether sandman is the intended name for the future cloud runtime or a separate abandoned idea is not something the repository settles.

The single release, tagged v0 and published on 2026-04-01, carries the body just getting this thing to work. That is a fair self-assessment and it should calibrate expectations: this is a prototype with a real architecture, not a product with a changelog.

## How Lunel compares with the usual phone coding setup

The obvious alternative is Termux plus an editor, and the comparison is fair enough to be worth making directly. Termux runs a real Linux userland on the phone, which means the tools are genuinely local and there is no second machine involved. Its weakness is everything that depends on the phone's own storage and battery: compiling on a phone is slow, background processes get killed, and a repository synced from elsewhere is a copy rather than a live working tree.

Lunel inverts that. The working tree, the git history and the shell all live on a machine you already maintain, and the phone is a thin display. In exchange you accept a network dependency, a session that expires, and the fact that the machine must be reachable and awake. If your work is on a server anyway, which is common for backend development, that trade is favourable.

The other comparison is SSH. Lunel is not trying to replace SSH, it is trying to replace SSH with a keyboard, and the README says so plainly. Whether a QR-code-paired mobile client is meaningfully nicer than a good SSH client with a good keyboard layout is a matter of taste, and one you can only settle by pairing with your own machine and trying to edit a file on a train.

## Conclusion

Lunel is a genuinely different answer to the SSH-on-a-phone problem, because it refuses to reimplement your tools and instead runs the ones you already have: real git, a real filesystem, a real pseudo-terminal in Rust. That design is what makes the phone app disposable, and it is why a plain text editor plus a terminal multiplexer has not been obsoleted by anything. What you give up is stability and trust surface. There is exactly one release, tagged v0, whose entire note reads as getting the thing to work, and the README's own framing admits the cloud half is not built yet. Start with Lunel Connect on a machine you own, run `npx lunel-cli`, and pair through the QR code before evaluating anything else. If the ten-minute session TTL or the missing cloud sandbox is the blocker for your use case, this project has not solved it yet.

## FAQ

### How do I connect Lunel to my computer?

Run the CLI on the machine you want to work on with npx lunel-cli. It connects to the manager and proxy servers over a WebSocket, and pairing happens with a session code scanned as a QR code from the phone app. Sessions carry a ten-minute time to live.

### What can the Lunel mobile app actually do?

The app provides a file explorer and editor, git integration, a terminal emulator and process management, and the CLI side covers filesystem operations, git commands, terminal spawning, port scanning and system monitoring for CPU, memory, disk and battery. It is built with Expo for iOS, Android and web.

### Is Lunel Cloud available yet?

No. The README lists Lunel Cloud as coming soon, and the only working path is Lunel Connect, which uses your own machine. The Makefile help text refers to a sandman component with build targets but flags it as not yet added, and no such directory appears at the repository top level.

### Why is there a Rust binary in a TypeScript project?

The pty/ directory holds a Rust binary for pseudo-terminal management that uses wezterm's internal libraries. It models the screen buffer as a grid of cells with a character and colours per cell, runs a 24fps loop that sends updates only on change, and speaks a JSON line protocol over stdin and stdout to the Node CLI.

## Sources

- [License: MIT](https://github.com/lunel-dev/lunel/blob/main/LICENSE)
- [lunel-dev/lunel on GitHub](https://github.com/lunel-dev/lunel)
- [Project website](https://lunel.dev)
- [README](https://github.com/lunel-dev/lunel/blob/main/README.md)
- [Releases](https://github.com/lunel-dev/lunel/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/lunel-dev-lunel