PERMISSIONS GUIDE

Who can do what

A shared Yeeted project has one owner and any number of members, each with a role. When a person works through an AI agent, a second set of limits applies: the permissions that person gave that agent connection. This guide lists what each role can do, where to do it on the dashboard and through your agent, and answers the situations people most often find confusing.

The four roles

• owner: the account the project belongs to. There is exactly one, and sharing cannot change who it is. Everything a member does on the project is billed to the owner's plan and limited by it.
• admin: everything the owner can do except delete the project, grant the admin role, or change or remove another admin.
• developer: reads everything, changes code, and works in development: deploys, secrets that are for development only, and development databases. Production stays with the owner and admins.
• read_only: reads the code, clones it, and sees logs and status. Changes nothing, and sees no secrets or databases.

What each role can do

Through an agent, each of these also needs the matching agent permission.

Where to do each thing

On the dashboard, open a shared project from the Projects tab; the project page shows your role next to its name. Through an agent, ask in plain words; the tool names are listed so you can recognise them in your agent's replies.

Agent permissions and roles together

An agent acts as the person who connected it. Each connection carries the permissions that person chose for it, on the permissions step when it first connects or later on the Connect agent tab. An agent can do something only when both allow it: the person's role on the project and the connection's permissions. Neither one widens the other. On the dashboard, signed in yourself, only your role applies.

Shipping a branch needs both Deploy apps and Read and change source code. Deleting a project also needs Delete databases and Delete secrets, because it removes them. A tool whose permission the connection lacks is hidden from the agent, and asking for it anyway is refused. A tool the connection holds is listed whatever your role on a given project is; your role is checked when the agent uses it. Each person chooses permissions for their own connections: a project's owner does not set them for a member's agent.

Worked examples

• A developer whose agent connection has no Manage secrets permission. The agent does not see secrets_list or secrets_set, and project_context leaves out the secrets section, naming it as not granted. The developer can still set a development secret on the Secrets tab, and the deployed app still receives every secret it is given: the permission limits the agent, not the app.
• An admin's agent without Deploy apps. It can read and edit code (with Read and change source code), but it cannot deploy, promote, roll back or ship, because shipping deploys. The admin can deploy from the dashboard, or tick Deploy apps for that connection.
• An agent asked to share a project. It needs Share projects, and its person must be the owner or an admin. project_share only asks: the invitation waits on the project's Members panel until the owner or an admin clicks Confirm, then the invited person is emailed and accepts on their own Invitations tab. A developer's agent is refused, and an admin's agent asking for the admin role is refused, because only the owner grants it.
• A read_only member's agent with every permission ticked. It can read and clone the code, read logs and check status. Every change it tries (an edit, a deploy, a secret, a database query) is refused by the role, with a reply saying so. Its project_context shows no secrets or databases, because a read_only member sees neither.

Inviting people

Sharing needs two people to agree: someone who may grant the access, and the person receiving it.

• From the dashboard, the owner or an admin enters an email and role in the Members panel and clicks Invite. The invitation goes straight to that person.
• Through an agent, project_share only requests it. It appears under Open invitations as "requested by ... through an agent; needs your confirmation" until the owner or an admin clicks Confirm. Until then the invited person sees nothing and gets no email.
• The invited person signs in with the address the invitation was sent to and clicks Accept on the Invitations tab. They need a Yeeted account but no plan of their own.
• An invitation expires 7 days after it was first made, whether it was waiting for confirmation or for acceptance, so a late confirmation leaves the invited person less time. An open invitation can be withdrawn at any time, and a person can have only one open invitation per project.
• Raising a role (picking a higher role on a member's row) is a new invitation the member accepts. Lowering takes effect at once. Only the owner grants admin, and only the owner can change or remove an admin.
• Leaving: any member but the owner can leave with Leave. Removing or lowering someone also withdraws the invitations they had sent.
• Billing: deploys, databases and usage on a shared project count against the owner's plan, never the member's.
• Erasure: when a member erases their account, they disappear from every member list and their invitations are removed. When an owner erases theirs, their projects are deleted and every member loses access.

Main, branches, production and hotfixes

• main is the project's code. The owner, admins and developers edit it with source_edit, or on a branch with source_edit(branch=...), and ship merges a branch into main and deploys development.
• Production runs a tested development build: promote moves it there. That is for the owner and admins.
• prod is the exact code production runs. A hotfix is a branch started from prod with hotfix (or source_edit(branch, from="prod")), previewed with deploy(branch=...) and shipped with ship(branch, to="production"); Yeeted then merges it into main. Starting, editing and shipping a hotfix is for the owner and admins, even to main. A developer can read a hotfix branch and deploy its preview.
• A hotfix may not change the database schema: migrations, ORM model and schema files and any .sql file are refused. Make those changes on main and ship them through development.
• revert undoes a range of changes on main as one new commit; it is a code change, so developers can use it.
• Claims (source_claim) tell other agents you are working on some files. They never block anyone. Developers and up can claim and close tasks; only the owner or an admin can clear someone else's claim.

Project-wide settings in yeeted.yaml

Most of yeeted.yaml describes the app, but four settings belong to the whole project: waf, depends_on, repo and the custom domain of each environment. A developer may edit these lines, but only the owner or an admin applies them. When a deploy uses code Yeeted already stores (a deploy by commit, redeploy, ship, promote, or the dashboard's Deploy and Relaunch) and that code's yeeted.yaml differs from what the project runs with, the difference is held:

• Owner or admin on the dashboard: before anything deploys, a question lists each change as "setting: current -> new". OK deploys and applies them; Cancel deploys the code and keeps the current settings.
• Owner or admin through an agent, when the client does not ask (see the next point): the code deploys, the project keeps its settings, and the reply lists them as held. Repeat the same call with apply_settings=true after reading the list to apply them.
• Owner or admin through an agent whose AI client can show a question: before anything deploys (for ship, before it merges), the client asks you directly, listing each change. Apply deploys and applies them; Deploy without deploys the code and keeps the current settings; Cancel deploys nothing. With no answer within 45 seconds the code deploys and the settings are held, as above. Clients that cannot show the question work as in the previous point, with apply_settings. Developers are never asked.
• Developer: the code deploys and the settings are not applied; apply_settings is ignored. The next owner or admin deploy of that code lists them.

source_blame on yeeted.yaml shows who wrote each line. To drop a held change, change yeeted.yaml back.

Secrets, databases and what development code sees

A secret is shared (used by both environments) or set for development or production only; one set for an environment overrides the shared value there. Nobody can read a secret's value back, owner included; only the running app receives it. A developer may set and delete development-only secrets and sees the names of all of them.

A developer's code runs in development with everything development has: secrets shared with both environments, the development copy of production data where your plan makes one, and your other development services. Give developer access only to people you would trust with that.

Edge cases

Why did my deploy skip my yeeted.yaml changes?

If you are a developer, project-wide settings (WAF, depends_on, repo, custom domains) are applied only by the owner or an admin; your code deployed without them. If you are the owner or an admin deploying through an agent, they were held because your client could not ask you, nobody answered in time, or you chose to keep the current settings: repeat the call with apply_settings=true to apply them. A yeeted.yaml that does not validate applies nothing, and custom domains also need the agent's Manage domains permission.

Why was my promote refused?

The reply says which case it is. What you are promoting is older than production (it lacks a fix production runs): to go back to an earlier version use rollback, otherwise deploy main to development and promote that. A shipped hotfix has not reached main yet because of a conflict: resolve it with source_edit(branch=<hotfix>, merge_main=true), ship it, then promote. There is no development build yet: deploy development first. Your role is developer or read_only: ask the owner or an admin.

Why was my hotfix refused?

The branch did not start from prod, it changes schema files, it lacks something production already runs, it carries commits merged in from main, or its tip has no tested preview. Start a fresh hotfix from prod for the first three, have the owner or an admin ship it into main for the fourth, and run deploy(branch=...) for the last.

Why can't my developer edit the hotfix branch?

A hotfix goes to production, so starting, editing and shipping one is for the owner and admins, even shipping it to main. Your developer can read it and deploy its preview, and can make the same fix on main or an ordinary branch.

My invitation says it is waiting for confirmation.

It was requested through an agent. The project's owner or an admin opens the project's Members panel and clicks Confirm. Only then is the invited person emailed.

The person I invited sees nothing on their Invitations tab.

It may still need confirmation, it may have expired (7 days from when it was first made) or been withdrawn, or they are signed in with a different email address than the one invited.

I was raised to admin but nothing changed.

A higher role is an invitation. Open the Invitations tab and click Accept. Only the owner can offer admin.

Accepting says the person who invited me can no longer grant this.

Their own role was lowered or they left, so the invitation was withdrawn. Ask the project's owner to invite you again.

Who pays for a shared project?

The owner. Members' deploys and databases count against the owner's plan and its limits, and a member needs no plan.

What happens when the owner deletes the project?

Its deployments stop, its databases and secrets are removed, and open invitations are withdrawn. Its stored code is kept for 30 days. Admins cannot delete a project.

Can an agent accept or confirm an invitation?

No. Confirming and accepting are done by people on the dashboard, whatever permissions the agent holds.

What does a developer's code see in development?

Everything development has: development-only and shared secrets, development databases, the development copy of production data where your plan makes one, and your other development services. See above.

Why does project_context not show secrets?

The connection may lack Manage secrets (the reply names the sections it left out), your role may be read_only, or the project has none. Databases, stored source and domains follow the same rule with their own permissions.

My agent lists deploy but says my role can't change production.

Which tools an agent sees follows the connection's permissions; whether a call succeeds also follows your role on that project. A developer deploys to development; production is for the owner and admins.

I clicked OK on the Deploy question and was told I don't have permission.

OK means production. As a developer, click Cancel to deploy development.

Setting a secret as a developer says insufficient permissions.

Choose development as its environment. Shared and production secrets are for the owner and admins.

My developer's agent deploy did not bring up the projects in depends_on.

Dependencies are project-wide settings, so a developer's deploy through an agent deploys only the project itself. Deploy each dependency, or ask the owner or an admin.

deploy_group refuses a project shared with me.

A group deploy runs as your own account, so it is refused on projects you do not own. Deploy each service with deploy.

A rollback to a checkpoint restored code but not data.

Restoring a database replaces data, so it needs the connection's Restore databases permission. Without it a checkpoint rollback restores code only.

Can an admin make someone else an admin or remove an admin?

No. Only the owner grants admin and changes or removes an admin. An admin manages developers and read_only members.

Two agents are editing the same files.

Claims are advisory and never block an edit. Check source_status before starting; each edit names the version of the file it read, so an edit made on a stale copy is refused with the current content instead of overwriting.

Continue

Read the full Yeeted documentation, or the preview and production guide.