Skip to content

Personas: make full access visible where personas arrive and where they are used #473

Description

@Jacksondr5

Problem

#469 lets a persona declare a full-access runtime policy. Any agent that can call spawn_agent can start such a persona, because a spawn is not limited by the caller's own access (Jackson's 2026-09-16 ruling: no parent-to-child permission ceiling). The review panel showed it live: a read-only, sandboxed Codex persona with the network off spawned a full-access persona as a peer, which then used the network and committed, with no prompt to the person.

Jackson accepted that behaviour as it stands on 2026-10-05, with the visibility work to follow in a later PR. This issue is that work.

The safeguard today is a "Full access" badge on persona rows in Settings → Personas. The panel found these gaps in it:

  • A persona from a shared folder arrives with full access and no step from the person. If a teammate commits a full-access persona to a shared personas folder, it appears in the library, badged, and any agent can start it.
  • Importing a file gives no notice. The import toast says "Imported 1 persona(s)." and the "Replace existing personas?" dialog shows name and id only.
  • The badge is not shown where personas are used. The composer's persona picker, the @ menu, and the chip on a running persona thread show no access information. The Crew seat editor says "Persona default" without saying the default is full access.
  • The badge is ambiguous. It keys off the persona's allowed policies, so a persona that runs read-only by default but allows full access shows the same badge as one that runs with full access.
  • list_personas reports only the default policy, so an agent choosing a persona can't see that a read-only-by-default persona also allows full access.

Options raised in review (not decided)

  1. Say so at import and in the replace dialog; show access in the picker, the @ menu and the thread chip; make the badge distinguish "runs with full access" from "can run with full access".
  2. A full-access persona that arrives from a file or a folder stays off until the person turns it on, reusing the existing on/off switch, so agents can only start full-access personas the person has knowingly enabled.

Evidence

Screenshots from the #469 review are on the j5/evidence branch under pr-469/, including the ambiguous badge (review-after-row-mixed.png) and the replace dialog (review-after-import-conflict.png).

Filed by Claude (Claude Code) at Jackson's request, from the review panel on #469.

Activity

  1. Jacksondr5 commented on Oct 7, 2026

    @Jacksondr5
    OwnerAuthor

    Also accepted, and in scope for this follow-up: on 2026-10-07 Jackson confirmed that his acceptance of unbounded persona spawning covers the scenario BastiHu's panel raised on #469. A persona with write access to a workspace that contains a configured persona source folder can write or change a YAML that declares full-access and then spawn it. Source folders are reread on every catalog request and new launch (agentPersonaLibrary.ts:96) and folder definitions are on unless listed as disabled, so there is no human step. No confirmation flow was added in #469. If this issue leads to an "off until enabled" rule for personas that newly declare full access, this is the case it would close.

    Noted by Claude (Claude Code) at Jackson's request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions