Six pnpm overrides, and package.json lags the release by design

Two credential routes, and one of them imports a config you already have

The pitch is a single line at the top of the README: your prompts, your model, your laptop. What sits behind it is a choice about credentials, and there are two.

One is bring your own key for any model. The README names Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Ollama, or any OpenAI-compatible endpoint, and the reason it lists Ollama in a design tool is that a local model removes the network from the loop entirely.

The other is subscription sign-in: direct ChatGPT Plus, Pro or Team sign-in for Codex models.

And then there is the import path, which is the one worth thinking about. One-click import of existing Claude Code or Codex provider configs, or one-click ChatGPT sign-in, gets you running in under 90 seconds.

That sentence is short and the consequence is not. Importing a provider config means reading credentials another tool is already using. For a security review, that is the first question to ask, and the repository does carry a SECURITY.md to ask it into.

package.json says 0.2.0 while the newest tag is v0.2.2, on purpose

The manifest and the release list disagree, and the manifest is not wrong.

package.json declares version 0.2.0. The three newest release tags are v0.3.0 from 2026-10-31, v0.2.2 from 2026-09-19 and v0.2.1 from 2026-05-23. The last push to the default branch, main, was on 2026-11-01.

The scripts explain the gap:

"release": "turbo run build && changeset publish"

with a separate version-packages script that runs changeset version. That is the Changesets model, where contributors add a changeset describing their change and the version number is only rewritten at release time. So main legitimately carries a stale version field while the published artefacts are ahead of it.

The practical consequence is that you cannot read the version off the source tree to tell what you have, and you should not try. Pin to a tag.

The What's new list also mixes a branch with released versions, which is a second reason the two are hard to compare. The top entry is a branch called feat/decompose-to-ui-kit, described as turning an image into a componentised ui_kits bundle for coding-agent handoff, with a boolean-per-dimension visual parity judge running twelve standard checks and a verify-and-iterate loop.

Four pnpm overrides, and one of them targets a relay

The dependency block has the same shape a security-conscious project uses: transitive packages forced forward by range.

"overrides": {
      "@xmldom/xmldom@<0.8.15": "0.8.15",
      "[email protected]>image-size": "-",
      "fast-xml-parser@<5.7.0": ">=5.7.0",
      "vitepress>vite": "6.4.2",
      "esbuild@<0.25.0": ">=0.25.0",
      "tar@<7.5.22": "7.5.22"
    }

Most are ordinary floors: on `@xmldom/xmldom`, `esbuild` and `tar`, while the vitepress override is scoped to the documentation site and the `[email protected]>image-size` entry removes that transitive dependency.

The interesting one is fast-xml-parser. XML parsing is not in the path of a tool that turns prompts into prototypes, and it is exactly what you need if you are ingesting SVG or OOXML. The README's example packs include an original low-fidelity SVG sketch, and the export formats include PPTX.

The rest of the toolchain follows the same discipline. Node 22 or later and pnpm 10.33.4 are declared:

"engines": {
    "node": ">=22"
  },

and there is renovate.json at the root for automated bumps, plus biome for lint and format and turbo for the task graph.

Queue follow-up and Steer next step are both non-interrupting

Two controls exist while a run is in flight, and the README is precise about what neither of them does.

Queue follow-up, bound to Enter, adds a text request for when the agent would otherwise finish. Steer next step supplies it after the current assistant response and tool batch finish. And the sentence that matters: it does not interrupt file writes, streaming tokens, permission decisions, or an unanswered agent question. The current run keeps its model, reasoning setting and workspace.

That is a design decision about correctness rather than about user experience. Interrupting a write or a permission prompt is how an agent ends up with a half written file and no record of why.

The rest of the paragraph is a list of things that are not done, which is where the useful detail is. Queued requests are explicitly marked pending until the agent receives them. Stop, errors or restarting the app leave undelivered requests recoverable and never automatically resent. Individual queue editing and removal is not supported. Active-run messages are text-only, so attached files, reference URLs and queued comments must be removed before sending and are neither silently included nor silently discarded. Delivery receipts use the existing local pi session JSONL rather than a separate database.

A tool that documents its non-features this precisely has been used in anger.

The example packs ship inputs, and the README says so twice

The Examples gallery has three editable starting points: Daymark with a Todo brief, task and project JSON, an original logo and design tokens; Common Ground with a workshop brief, a schedule CSV and original artwork; and Trailhead with an original low-fidelity SVG sketch, an annotated brief and trip data.

Selecting a pack creates a fresh workspace and copies its reference files before filling the composer, and the README is explicit about what that means. Nothing is submitted automatically, and no existing workspace is overwritten.

Then the disclaimers, and there are three of them in one paragraph. These are fictional MIT licensed packs that contain inputs, not prebuilt final interfaces. Tags describe supplied references and requested prototype behaviour, not verified generation results. And bookings and other data are simulated, with the sketch carrying text annotations for models that have no image input.

That is an unusual amount of care for a demo gallery, and it points at a habit worth checking elsewhere in the project: the same paragraph then states that a missing App.jsx does not mean reference inputs are missing, because the agent can inspect them before building.

Preflight gets a bounded file list, and DESIGN.md is honoured

The agent's access to your files is the part of this design with the sharpest edges, and the README is unusually specific about the limits.

Preflight receives a bounded, non-exhaustive list of existing workspace file paths, and recognises local DESIGN.md guidance. Local CSV references are included in that bounded text-file scan alongside Markdown, JSX, JSON and SVG inputs.

Bounded and non-exhaustive are doing real work in that sentence. Non-exhaustive means the list handed over is a sample rather than a complete inventory, so a file the agent never saw mentioned is not evidence that it does not exist, and an absent App.jsx is explicitly called out as an example.

On the output side the same bounded idea appears. Preview and final verification resolve local assets relative to the source file inside the bound workspace, and missing assets and paths outside that workspace remain verification errors rather than warnings.

So there are two boundaries and they are different in kind. Reading is bounded and sampled. Assets that are missing or outside the workspace fail verification. The DESIGN.md support is also worth noting: v0.2.0 lists DESIGN.md design systems as one of its headline changes, so a project can hand the agent its own rules rather than describing them in every prompt.

An Electron app with Homebrew, winget and Scoop manifests

The packaging story is short and the last entry in the What's new list is the one that matters.

v0.1.2, dated 2026-04-21, is titled Release pipeline and Homebrew, winget and Scoop packaging manifests. So an Electron desktop app was given Homebrew, winget and Scoop manifests rather than being distributed only as a download from a page, which is a small decision with a large support consequence.

The README's header links a Website, a Quickstart section, a Docs page and a What's new link pointing at the releases page.

The root of the repository shows the rest of the shape. There is apps/, packages/, docs/, website/, examples/ and a packaging/ directory, which is consistent with the website being a separate workspace package that the docs scripts target by name. examples/ contains a single directory, calm-spaces, and examples/calm-spaces/ is the only example folder listed.

The root also holds BENCHMARKS.md, referenced by the decompose branch entry, and CITATION.cff, among other documentation files.

Editorial conclusion

Take Open CoDesign if you want an AI design tool that runs on your machine and talks to a provider you already pay for, including a local Ollama endpoint, and you are willing to accept that the exported interface is generated rather than designed. Leave it if you want a hosted product with somebody else's machines, because the local-first, bring-your-own-key positioning is the product rather than a feature of it. Verify four things. Read SECURITY.md before you point the app at a real workspace, since security hardening is one of the changes v0.2.0 lists for itself. Decide which credential route you take, because one-click import of an existing Claude Code or Codex provider config is a different decision from pasting a key into a form. Check the releases page rather than the manifest for the version, because package.json records 0.2.0 while the newest release tag is v0.3.0 and Changesets moves that number at release time. And expect a bounded agent: preflight receives a non-exhaustive list of workspace file paths and recognises a local DESIGN.md.

Frequently asked questions

Official sources

1. License: MIT
2. OpenCoworkAI/open-codesign on GitHub
3. Project website
4. README
5. Releases