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)
- 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".
- 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.
Problem
#469 lets a persona declare a
full-accessruntime policy. Any agent that can callspawn_agentcan 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:
@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.list_personasreports 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)
@menu and the thread chip; make the badge distinguish "runs with full access" from "can run with full access".Evidence
Screenshots from the #469 review are on the
j5/evidencebranch underpr-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.