Collaboration and access

Share a project

1. Choose Manage access from the project menu.
2. Search by email and choose a role.
3. Select who pays for that collaborator's agent work when the plan permits it.

Every invitation requires explicit acceptance, including invitations to existing verified accounts. The recipient opens the invitation and accepts it using the invited email address before it expires; a new account must first register and verify that address.

Project sharing can depend on the owner's plan. If the capability becomes unavailable, membership settings remain stored but collaborator access pauses until eligibility returns. Archived projects are owner-only.

Leave a shared project

Open Manage access and choose Leave project, then confirm. Your row is marked You. Leaving removes your membership without deleting the project or other users' work. You will need another invitation to rejoin. The owner transfers ownership instead of leaving. Removing participants uses a separate action and cannot remove your own membership.

Roles

• View only can inspect the workspace, live preview, chats, integration catalog, and file history. When opening a project, an existing conversation is selected without restoring a message draft. The chat input and its action buttons stay visible but disabled, with the notice You don't have permission to make changes. Code, Environment, Integrations, Gateway, Devices, and Settings use the same notice when your role does not allow changes there.
• Editor can use the agent, change the project, restore a file version, and manage publishing.
• Full access adds chat archiving and restoration, environment and integration management (including GitHub repositories), publishing, runtime controls, project instructions, and membership management. For owner-plan features, the invited user's personal plan does not replace the owner's entitlement.
• Owner adds project archiving, restoration, and ownership transfer.

Available actions depend on your project role and the relevant plan feature. A visible tab can still be read-only. A plan restriction on manual Code editing or Database Studio does not remove the Editor's ability to request agent development; project roles and credit requirements still apply. Badge removal is checked against the publishing account; see Publishing and domains.

The Chats list and History show unavailable editing actions as disabled controls without a separate role notice. View-only members can select older versions for preview and return to the current version; restoring files requires editing access. See History and restore.

Agent access across projects

You can explicitly ask Amazi to work with another project you own. Mention it through @ → Projects in chat. Only owned projects are available there; shared membership and an unfinished ownership transfer do not qualify. Amazi checks ownership on every request, so transferring the project stops further access from another chat. In an open shared project's chat, Editor and Full access members can ask Amazi to inspect applications and change the project. Environment and integration tools require Full access. These permissions follow your current role, including after it changes. The agent does not inherit access to other projects belonging to that project's owner.

Payer and ownership

For a new invitation, the invited user is the first payer option and is selected by default when they have a paid plan. Without a plan, or before registration, the owner is selected instead. You can choose the owner for a paid-plan recipient. Editing an existing membership preserves its payer choice.

Collaborator tasks can charge the owner or an eligible paid-plan collaborator according to membership settings. Amazi fixes the payer when it accepts a task; later role changes do not move that task's charge. Only the current owner can start an ownership transfer. After completion, the former owner keeps access only if the new owner grants it.

Invitation and ownership dialogs

Invite user collects an email, role, and available payer choice. Registered recipients can accept invitations in Inbox even if email delivery fails. If an email-only invitation cannot be delivered, check the address and try again. Sending creates a pending invitation; it does not silently add an existing account. The recipient must open and accept the invitation with the invited address. Project access shows the owner and invited users with role, credit payer, status, and permitted actions. Controls can be read-only because of your role or the owner's plan.

Transfer ownership sends an invitation by email, just like inviting a collaborator. Registered recipients can also open it from Inbox. The recipient has 24 hours from sending to sign in with the invited address and explicitly accept; a new account must first register and verify that address. Sending or opening an invitation does not give the recipient access. You remain the owner until acceptance and can cancel the invitation. Acceptance changes the owner immediately and removes your project access, including any previous membership. There is no additional 24-hour access period. If the invitation expires or is canceled, the project stays with you.