> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.mythos.new/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.mythos.new/_mcp/server.

# People and permissions

> Invite your team, share individual projects, and choose the access each person needs.

Invite someone to your workspace when they are part of the team. Share a single project when they
only need to work on that app. These choices give different access, so start with the scope of the
work you want to share.

**People** manages workspace membership. A project's **Share** dialog manages access to that project.
Neither is the same as publishing your app for visitors.

Team invitations, role management, and member credit limits require an active **Pro or Business**
subscription. Room requires **Business**. Your role must also permit the action: upgrading a plan
does not grant administrative access. See [Credits and usage](/introduction/credits-and-usage).

## Open People

Go to **Workspace settings → People**. The list lets you find members and pending invitations, see
roles, and review credit usage. Use search and the role filter to find a person; use the
**Invitations**, **Collaborators**, and **Requests** tabs to focus on a particular kind of access.

Available actions depend on your role. Workspace owners and admins can manage the team. People with
less access see the controls available to them. External project collaborators do not receive the
full workspace member directory.

## Roles and permissions

Your workspace role and your project role answer different questions.

| Workspace role | What it means                                                                             |
| -------------- | ----------------------------------------------------------------------------------------- |
| **Owner**      | Can manage workspace membership and settings, including owner-level controls.             |
| **Admin**      | Can manage the team and shared settings within the available permissions.                 |
| **Editor**     | Can work on projects they can access; this is not permission to administer the workspace. |
| **Viewer**     | Can view accessible projects without editing their code.                                  |

Workspace owners and admins have administrative access to workspace projects. A workspace Viewer
remains read-only even if a project invitation would otherwise grant editing rights.

In a project's **Share** dialog, the access choices are:

| Project access | What it allows                                                      |
| -------------- | ------------------------------------------------------------------- |
| **Can view**   | Open and inspect the project without changing its code.             |
| **Can edit**   | Build and edit the project.                                         |
| **Admin**      | Edit the project and manage its access and administrative controls. |

The Share dialog only offers access you are allowed to grant. For example, a project Viewer can
grant or remove Viewer access; that does not let them invite an Editor or change the app.

Publishing has an additional workspace rule. A project Editor may be able to build while being
unable to publish, update the public URL, or manage domains. See
[Privacy and security settings](/introduction/privacy-security).

## Invite a teammate to the workspace

1. Open **Workspace settings → People**.
2. Choose **Invite members**.
3. Enter the person's email address and choose the appropriate role.
4. Review any confirmation for elevated access, then send the invitation.

Pending invitations appear separately from active members. Review the invitation's expiry and
revoke it if it is no longer needed. If an invitation has expired, send a new one.

Use **Invite link** when a shared invitation is appropriate. Check the role before copying the link.
Anyone who receives a valid invitation link may be able to use it, so share it only with the intended
people. Rotating or revoking the link changes whether the old link can be used.

Workspace policies can limit invitations or invite links. If a control is unavailable, ask a
workspace owner or admin to review the relevant setting.

## Share one project

Open the project and choose **Share**. Enter the person's email, select **Can view**, **Can edit**, or
**Admin** from the available choices, and send the invitation.

Use **Can view** for someone reviewing progress, **Can edit** for someone building with you, and
**Admin** only when the person should manage the project's people and access.

Someone outside the workspace can receive access as an external collaborator. Their access applies
to the shared project; it does not make them a workspace administrator. Workspace policies may block
external collaboration or cap the role you can offer.

The dialog lists people with project access and pending invitations. Review both before changing
access. Removing an explicit project invitation may not remove access someone still has through
workspace membership.

### General access

Project settings also include **General access**, which controls how workspace members can access
that project. Check it together with individual invitations. A project shared with the workspace
can still be reachable through that shared access after you remove one person's explicit grant.

Choosing restricted project access inside a team workspace requires Business.
Choose access based on the audience you intend. This setting controls the project in Mythos, not
who can sign in to the app you build.

## Work together in Room

**Room** is the project's space for human conversation. Use it to discuss a design, share context,
and coordinate who is making the next change.

Posting a message to a teammate in Room is different from sending a Build request to Mythos. Keep
the change you want Mythos to implement in the project composer. A decision discussed in Room does
not automatically change code, Knowledge, or the published site.

Project access and conversation access still matter. A preview link does not make its recipient a
Room participant or give them editing rights.

## Project invitations, preview links, and Publish

Use the right sharing action for the outcome:

| Outcome                             | Use                                            |
| ----------------------------------- | ---------------------------------------------- |
| Work on the app together            | A project invitation with the appropriate role |
| Let someone inspect a preview       | The available preview-sharing flow             |
| Put the app on the web for visitors | [Publish](/publishing/publish)                 |

Review what a link exposes before sending it. A published app has its own visitor experience; its
authentication and data permissions are separate from Mythos workspace membership.

## Review usage and access

People shows credit usage and supports monthly Build-credit limits. An individual limit overrides
the workspace default for that member. Use **Set credit limit** from the person's menu when you need
a specific allowance, and review the displayed value before saving.

A person working on a shared project uses that project's workspace credits. Their personal balance
is not a substitute for the workspace's available balance and permissions.

You can export the member list as CSV where that action is available. Use the list and user insights
to review who still needs access, especially before removing a teammate.

## Change or remove access

Use the role control or member menu in People to adjust workspace access. Owner-level and billing
ownership changes require the corresponding authority; an admin role is not interchangeable with
ownership.

For a project-only change, use its Share dialog instead. Revoke an unused invitation, remove the
explicit grant, or adjust General access as appropriate.

Removing access is not a request to delete the person's work or unpublish an app. Review the
confirmation and any remaining workspace or project grants before assuming the person has no
access left.

If someone cannot open a project, first check the account they used to sign in, the invitation,
their workspace membership, and any connected-tool access the project requires. For an action that
is unavailable inside the project, compare their role with the workspace's relevant restriction
before sending another invitation.