Airship Visually Edits Your Running App

Airship is a local visual editor by 0xnyn that sits in front of your running dev server and sends UI changes to Claude Code, Anthropic's coding agent; Codex CLI, OpenAI's command-line coding agent; or OpenCode, SST's terminal coding agent. It deals with the annoying gap between sketching UI ideas and changing the implementation that actually ships. For Codex users following a codex cli github workflow, the takeaway is simple: visual editing is only interesting if it ends in source diffs, tests, and a normal review loop.

Airship is a visual editing layer for a real app, not a separate design file. You start your app, point Airship at the local URL, select an element, describe the change, and let your existing coding agent update the code.

Why developers noticed Airship

The Show HN pitch was easy to understand because the pain is real. Frontend developers often try a layout idea in Figma, rebuild it in React, discover the real component constraints, then go back and adjust the mockup. Airship tries to remove that loop by making the running app the canvas.

The project’s README describes an infinite design canvas in front of your dev server. It says Airship works with apps that serve HTML over HTTP, including Vite, Next, Remix, Rails, and similar stacks. It also says there is no plugin, no config, and nothing added to your app dependencies or bundle.

That last part is why AI-coding developers paid attention. A visual editor that requires a custom runtime, a component wrapper, or a build-time plugin becomes another platform decision. Airship’s bet is smaller: keep your app running normally, use the agent auth you already have, and write back to the existing source.

As of August 11, 2026, the public repository showed 19 GitHub stars, an MIT license, TypeScript as the main language, and same-day activity. That is early-project territory. The right way to read it is not “this replaces your editor.” It is “this is a sharp experiment in making coding agents feel less blind when the task is visual.”

The trick is editing the implementation, not the mockup

Airship’s useful move is that it starts from the page you can already run. A designer-ish interaction happens on top of the local app, but the desired ending is a code change in the repo.

Imagine a Next.js settings page with a noisy billing card. In a normal flow, you might screenshot it, annotate it, ask Codex to tighten spacing, then manually explain which component owns the card. In Airship, the element selection becomes part of the prompt context, so “make this card less tall and move the secondary action under the price” has a better chance of landing in the right component.

The trap is expecting Figma, by Figma Inc., to disappear from product design. Airship is not a system-design tool, a brand library, or a stakeholder review surface. It is more like a visual handle for implementation experiments.

That distinction matters. The closer the question is to “how should this real component look in this real app state?”, the more Airship makes sense. The closer the question is to “what should the whole product experience become?”, the more you still want design exploration outside the repo.

Fit it into a Codex CLI loop

For Codex users, Airship belongs inside the same loop you already use for Codex CLI workflows: make a small change, inspect the diff, run the app, run tests, and commit only what survived review. The visual editor should shorten the prompt-to-diff path, not replace verification.

A practical loop looks like this:

# terminal 1: run the app normally
npm run dev

# terminal 2: point Airship at the local app
airship --target http://localhost:3000

# after the agent edits files
git diff
npm test
npm run lint
npm run build

If you prefer Airship to manage the app process, the README describes an --exec mode that starts the dev server and stops it when Airship exits. Check the project’s CLI reference before scripting this into anything durable, because the project is still young.

Keep one Codex artifact close to the repo. A tiny AGENTS.md note is enough for this kind of visual work:

# AGENTS.md

## UI edits
- Prefer small diffs that preserve existing component boundaries.
- Do not rename design tokens unless the task explicitly asks for it.
- After visual edits, run: npm test, npm run lint, npm run build.
- If the selected element is generated from shared data, explain the data path before editing.

## MCP boundary
- Treat production data tools as read-only during UI experiments.
- Do not call write-capable MCP servers for visual-only changes.

That note is not bureaucracy. It tells the codex agent what “safe” means in this repo. In a codex cli github flow, it also gives reviewers a stable standard for judging whether the visual edit was a clean implementation change or a wandering refactor.

There is a nearby pattern here with browser-wrapped agents, like Mirafold Wraps Coding Agents in Browser UI. The interesting bit is not the chrome around the agent. It is whether the UI gives the agent better, narrower context without hiding the patch.

Try Airship safely on one screen

Start with one screen that is easy to rebuild and easy to judge. A settings panel, pricing card, onboarding step, or empty state is better than a checkout flow with payment side effects.

Use this quick fit check before you spend an afternoon on it:

A safe first experiment is small: “tighten spacing and improve hierarchy on this account card.” Do not ask for a new design system, a responsive rewrite, and a copy pass in one prompt. Visual context helps, but it does not make broad instructions precise.

Here is the lightweight checklist I would use before trusting the result:

• Start from a clean branch.
• Run the app yourself before opening Airship.
• Select one element or one small region.
• Ask for one visible change.
• Inspect git diff before refreshing your expectations.
• Run lint, tests, and build.
• Revert anything that changes unrelated files.
• Commit only after you can describe the change in one sentence.

The best sign is a boring diff. A CSS class, a token swap, a small component adjustment, maybe a prop change. If the patch rewrites half the page, the visual editor did not fail exactly, but the task got too loose.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Codex artifact first: an AGENTS.md instruction, a Codex CLI verification loop, an MCP boundary note, or a skills handoff.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about codex cli github?

  Start by writing down one visible team rule for Codex, not a loose preference. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Codex artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a AGENTS.md instruction, MCP note, or verification checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Codex teams deciding which AGENTS.md instruction, CLI workflow, MCP boundary, or verification loop to standardize next around “Airship Visually Edits Your Running App.”
• Best first artifact: turn the named fix into an AGENTS.md rule, verification checklist, MCP note, or review receipt before the next automated run.
• Best comparison angle: compare the workflow against the current Codex CLI review loop, shell boundary, and evidence trail; keep the path that leaves the shortest auditable trail.

Further reading

• airship — source
• OpenAI Developers — Codex CLI
• GitHub — openai/codex
• OpenAI developers: codex quickstart

Next move

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.