Make “Full Access” reflect the effective worker sandbox and external write roots

[Hmbown]

Summary

The UI can display Full Access while a delegated worker is still unable to write outside the workspace root, including user-owned CodeWhale paths such as ~/.codex/tmp and ~/.codex/pets. It can also have no shell-execution tool available.

That may be an intentional host/executor safety boundary, but it is not communicated accurately by the Full Access label.

Observed in v0.9.0

A task in /Users/hunter/pets ran under a visible Full Access posture, then received permission errors when its documented export/install pipeline attempted to write to user-owned ~/.codex/ locations. The model had to discover the restriction by failed writes and could not complete the install step.

Expected

• The UI must show the effective authority of the active worker, including:
  • shell availability,
  • effective sandbox type,
  • workspace root,
  • external paths that are read/write allowed,
  • whether Full Access can actually lift the underlying host sandbox.
• If a host sandbox remains workspace-bound, do not present the state as unqualified “Full Access”; use wording such as Full Access · workspace-bound worker and show the permitted roots.
• Full Access should either propagate to the child tool context as documented, or the UI/docs should explicitly explain the narrower worker policy.
• Task setup should preflight known destination paths and explain the required trust/elevation before starting a build that will need them.

Acceptance criteria

• Regression test starts a Full Access parent/worker with an external user-owned destination and verifies the capability report matches actual write behavior.
• The permission/footer/status UI exposes effective restrictions rather than only intent.
• Failure message offers the relevant recovery (trusted path, workspace staging, elevation, or user copy command) without implying the task has installed an artifact.