Airship: a visual editor that drives Claude Code, Codex or OpenCode against your running dev server

The gap Airship fills between a running page and a coding agent

Most agent-driven UI work happens in text. You describe a button in a prompt, the agent guesses which file renders it, and you reload to find out whether the guess was right. Design tools solve the pointing problem but not the source problem: the canvas holds a copy of the UI, and someone has to port the change back by hand.

Airship takes the position that the running page is the design surface. The README describes it as a visual editor for your codebase that puts an infinite design canvas in front of your dev server. You select an element, describe the change, and the agent updates the source. The audience is narrow and specific: developers who already use Claude Code, Codex or OpenCode and want to select rather than describe. It is not a design tool for people who do not touch the code, and it is not a component library.

How Airship sits in front of your dev server

The architecture is deliberately shallow. Airship is a CLI and nothing else, per the README. It connects to the port your app is already serving and opens the editor on the next free port. The Makefile in the repository states the same convention from the other side: the overlay always takes TARGET + 1, so a dev server on 5173 puts the editor on 5174.

Because the frames are real browser windows rather than rendered screenshots, a phone frame behaves like a phone at any zoom level, and a desktop frame and a phone frame can sit side by side, both live and both driven by the same source file. Clicking an element resolves to the file and line that drew it, which is what makes the agent handoff possible at all. The README states that no plugin is required and that nothing is added to your dependencies or your bundle, which is why the tool works against Vite, Next, Remix, Rails, or anything else that serves HTML over HTTP.

Two modes change what the editor is pointed at. Canvas mode is the default: your app on a pannable canvas, one live frame per device size. Inline mode puts the editor on top of your own page in a single window. The mode is chosen at launch or from the bottom bar, and the choice persists across reloads. The README notes a detail worth remembering: the URL parameter takes the internal mode name, so returning to the canvas is `?__airship=shell`, not `?__airship=canvas`.

Installing Airship and making a first edit

Airship needs Node, and the repository's package.json sets the engine floor at Node 22.13.0. Start your app the way you normally do. The README's example uses pnpm on port 3000.

pnpm dev    # http://localhost:3000

With the dev server running, point Airship at that port. The CLI connects to the port you are already running and opens the visual editor on the next free port, so in this example the editor lands on 3001.

npx @airshiplabs/cli --target 3000

If you would rather not invoke it through npx each time, the README gives a global install and then the `airship` binary.

npm i -g @airshiplabs/cli
airship --target 3000

To bring an agent in explicitly, pass the agent name. The `--safe` flag appears in the README's example alongside `--agent codex`, and the tool uses the authentication you already configured for that agent rather than asking you for new credentials.

airship --target 3000 --agent codex --safe

If the agent connection does not come up, the README points at one command: `airship doctor`. There is also a mode where Airship starts and stops the dev server itself. `--exec` runs your dev command and shuts it down when Airship exits, and if you leave `--target` off it reads the port from your package.json.

airship --exec "pnpm dev"

Run `airship` with no arguments and it prompts for the port, the agent and the mode. Once inside, the workflow is: click an element, describe the change, read the diff the agent produces, and undo it with the platform undo shortcut if you do not like the result. The README's control table lists `⌘Z` on macOS and `Ctrl+Z` elsewhere.

What the inspector and the two edit modes actually expose

Selecting an element fills the inspector, and the README is explicit that every tab is looking at the same element. The Edit tab covers position, size, spacing and layout. The CSS tab shows the box model, the rules that are actually matching the element, and your own overrides layered on top. The DOM tab is the tree: click a node to select it, or drag one to move it.

The Edit and View modes are a real distinction rather than a cosmetic toggle. Edit is about an element, so the agent panel and inspector are open on either side of the selection. View is about your frames: the page underneath stays fully interactive, so you can click through it, fill in forms and scroll, but element selection is off and the two panels that depend on a selection step aside. In their place the left panel lists every frame and a minimap appears in the bottom right. The frame list is stacking order with the front-most at the top, and dragging a row restacks frames that overlap on the canvas. Panel arrangement is remembered per mode, so switching back restores the inspector where you left it.

One small piece of engineering is worth calling out because it is the kind of thing that usually rots. The README says the controls table is generated from the editor's own command catalog, which is why it cannot drift from what the keys actually do. The repository carries a CONTROLS.md alongside it. That is a stronger guarantee than a hand-maintained shortcut list, and it is verifiable by reading the build rather than trusting the docs.

Where Airship stops being the right tool

The constraint is the same one that makes the tool work. Airship runs in front of a dev server that serves HTML over HTTP. If your UI is not reachable that way, there is nothing for the overlay to attach to. A native mobile app, a desktop application, a canvas-rendered WebGL scene, or a page whose markup is generated in a way the dev server does not report as root-relative URLs will not give you the element-to-file mapping the whole workflow depends on. The Makefile is candid about the resolution step: Airship resolves the root-relative URLs the dev server reports, such as `/src/app.tsx`, against the dev server's root rather than the repository root. That is a real assumption about how your tooling reports paths.

There is a second, softer limit. Because nothing goes into your project, Airship also knows nothing about your project beyond what the running page and the resolved source files tell it. It is not a type checker, a test runner or a build system. An agent edit that passes visually can still break a type or a test, and the README describes no verification step after the diff lands.

Finally, the versioning story is thin. The repository's root package.json carries version 0.0.0 and is marked private, which is normal for a workspace root, but no releases were retrieved, so there is no changelog to read for upgrade guidance.

How Airship differs from Storybook-driven and browser-devtools workflows

The nearest thing in most front-end repositories is Storybook. The difference is where the component lives. Storybook renders components in isolation from stories you write, so the canvas is a set of fixtures you maintain, and the file that draws a given element is the story you wrote. Airship renders your actual running app and resolves the element back to the file and line that drew it, so there are no stories to keep in sync and no separate component harness. The cost is that you cannot inspect a state your app cannot reach. A component that only appears behind a feature flag, a payment flow or a seeded account is easier to isolate in a story than to reproduce inside Airship.

Browser devtools are the other comparison, and the gap is the same in a different direction. Devtools let you edit CSS in the page, and the change dies on reload. Airship routes the described change through a coding agent that writes to source, which is why undo is a source-level operation rather than a stylesheet override. If all you want is to nudge a padding value and see it, devtools are faster and involve no agent. Airship earns its place when the change needs to persist in the codebase and you would rather point than describe.

Licence, maintenance and what an upgrade costs you

Airship is MIT licensed. For most teams that means the usual permissions to use, modify and redistribute with the copyright notice retained, and no copyleft obligation on your own code. This is not legal advice; read the LICENSE file in the repository if your organisation has specific requirements about attribution or about bundling third-party tools into an internal workflow.

On maintenance, the last push to the repository was on 2026-09-14, and the repository is not archived. That is recent activity, and the workspace layout (turbo, pnpm workspaces, a Husky and commitlint setup, a Makefile with a preflight target) suggests a project that is being worked on rather than parked.

The upgrade cost is unusually low by design, and that is the point of the architecture. Because Airship is a CLI that runs in front of your dev server and adds nothing to your dependencies or your bundle, there is no version to bump inside your application and no lockfile entry to reconcile. Upgrading means running a newer version of the CLI. The one thing to watch is the Node floor: the repository's package.json sets `engines.node` to `>=22.13.0`, so a machine below that will not run it. Teams that pin Node per project should check that requirement before adding Airship to a workflow.

Editorial conclusion

Adopt Airship if you already run a coding agent and want to point at a rendered element instead of describing it in a terminal, and if your app serves HTML over HTTP from a dev server you control. Do not adopt it if your UI is not reachable as a local HTTP page, or if you need the editor to be a dependency your build knows about, because the README states nothing is added to your project. Verify first that `airship doctor` reports your agent's existing authentication as usable, and check that the port Airship picks (target plus one) is free on your machine.

Frequently asked questions

Official sources

1. 0xnyn/airship on GitHub
2. Issues
3. License: MIT
4. Project website
5. README