Claude Design "Projects" imply a durable two-way link that does not exist
The core problem
The vocabulary sets an expectation the product does not meet. "Project," "Link local code," and "GitHub connected" all imply a persistent, two-way relationship with a codebase. In practice a Design Project is a disposable, one-off starting point, and the code link is read-only (repo to Design as context). There is no sync back. This applies to everything a Project produces: documents, websites, wireframes, prototypes, UI mockups, any design or UX artifact.
What actually happens
Only design systems get live two-way sync via /design-sync. A Project does not. Once its output is handed off or exported to a repo, the link is dead: editing the repo files does not update the canvas, and editing the canvas does not update the repo. Nothing reconciles them.
Why this bites in practice
Because Projects are really just starting points, anyone who uses Claude Design regularly ends up with a long, growing list of one-off "projects" that have no ongoing purpose after the first export. They are named like durable things but behave like throwaway drafts. This is confusing, and it makes the sidebar unusable over time.
What gets lost, and why sync is the answer
The canvas is not just a starting point, it is a better surface for editing design work than code is. Whether it is a document, a website, a wireframe, or a prototype, you can manipulate things directly, drop in images, spot a small visual change and hand-edit it, and move fluidly between asking the model and editing it yourself. Claude Code cannot do any of that. So when the work leaves for the repo, you lose the single best reason to have used Claude Design at all, and you are back to describing every change as text.
This is the crux. The canvas UX is worth keeping. A one-way handoff forces a trade: give up the better editing experience in exchange for durable, repo-backed files. A real two-way sync removes that trade. You draft and tweak visually on the canvas, the files stay live in the repo, and you edit in either place depending on what the change needs.
The misleading part
"Link local code" and "GitHub connected" strongly suggest a live link. A user reasonably assumes changes flow both ways. They do not. The connection is inbound context only.
Requested
If these are going to be called Projects and offer code linking, make the link real: a two-way sync between a Claude Code project and its Claude Design project, the way /design-sync already works for design systems. This should cover any Project output, not just one artifact type. At minimum, make "Link local code" bidirectional so a Project can write its files back to the linked repo and stay in sync. Failing that, the naming should be honest about the one-way, one-off nature.