Add a developer to your vibe

You can now let another person edit and ship your vibe — push code, publish, run codegen — without handing over your account. It takes one command, or one row in a new Developers section of the sharing panel. And you keep the controls that matter: nobody but you can revoke that access, unpublish the app, delete it, or hand off ownership.

What a developer can do

Grant developer access on a vibe and that account can work on it as if they were building it:

• Edit and push code — pull the source, change it, and push new versions live from the CLI.
• Publish — promote a draft to the public production release.
• Run codegen — drive follow-up prompts that regenerate the app, via the CLI's edit command.
• Read its data and secrets — editing code that talks to the database means seeing what the database holds, so a developer gets full read access to the vibe's data and its per-vibe secrets. Their handlers actually work.

What stays owner-only

A developer grant is deliberately not a transfer of ownership. No matter how many developers you add, these levers never leave you:

• Unpublish or delete the vibe.
• Grant or revoke developers — a developer can never add or remove anyone, not another developer and not themselves, so this control always stays with you. Revoke one and every new push, publish, and data read is denied from that moment; a live session they already had open ends the next time it reconnects.
• Transfer ownership.

The thing to internalize: a developer is not locked out of your data or secrets — they can read both, because you can't edit a backend without them. What the owner keeps is the destructive and ownership levers. That's the line the grant draws.

Two ways to grant it

From the CLI. The vibes-diy developer commands manage grants from the shell, targeting a vibe the same way the other commands do (--vibe handle/app-slug, or --app-slug defaulting to the current directory):

sh# Grant developer access on the current vibe to @alice
vibes-diy developer add alice

# List every developer on a vibe (active and revoked), newest first
vibes-diy developer ls --vibe jchris/hat-smeller

# Revoke a developer
vibes-diy developer rm alice --vibe jchris/hat-smeller

developer ls takes --json for machine-readable output, so a script can read the grant list. Only the owner can run the mutations — a developer who tries to add or rm gets an owner-only error back.

From the sharing panel. Open the vibe's Share panel (or App Settings → Sharing) and you'll find a new Developers section alongside who-can-see-it. Type a handle, click Add developer, and it appears as active; Revoke flips it to revoked and shuts the door on any further access. Its tooltip spells out the whole deal:

A developer can edit this vibe's code — push, publish, and run codegen — and read all of its data and secrets. You keep control: only you can grant or revoke a developer, unpublish or delete the vibe, or transfer ownership.

Why it's built as a separate capability

On this platform, roles gate data. An editor grant lets someone write your app's database — it does not let them touch the source. That separation is deliberate, and it's why developer access isn't just another data role.

Pushing code is a sharper, different thing than writing a document, so it gets its own capability rather than being folded into the data-sharing ladder. A developer grant is issued to a handle and checked against the developer's account — so it works from any of their handles — and it fails closed on rebind: if that handle is ever released and picked up by a different account, the grant goes inert instead of quietly following the name.

That's the whole idea: collaboration on the code without diluting who owns the app. The person building alongside you can ship all day; the app is still unmistakably yours.

Read the docs

The full reference — everything a developer can and can't do, and how to grant, list, and revoke from either surface — lives at Developer Grants.