Surface filesystem permission profiles in prompt context

[bolinfest]

Summary

Some permission profiles can encode filesystem reads that should remain unavailable to the agent. Before this change, the model-visible context and automatic approval review prompt summarized the effective permissions as a legacy sandbox mode, which can omit permission-profile filesystem entries from escalation decisions.

For example, a profile can grant workspace access while denying a private subtree across every workspace root:

default_permissions = "restricted-workspace"

[permissions.restricted-workspace.workspace_roots]
"/Users/alice/project" = true
"/Users/alice/other-project" = true

[permissions.restricted-workspace.filesystem]
":minimal" = "read"

[permissions.restricted-workspace.filesystem.":workspace_roots"]
"." = "write"
"private" = "deny"
"private/**" = "deny"

The context window now describes the workspace roots and effective filesystem side of the PermissionProfile directly, with deny entries marked as non-escalatable:

<environment_context>
  <cwd>/Users/alice/project</cwd>
  <shell>zsh</shell>
  <filesystem><workspace_roots><root>/Users/alice/project</root><root>/Users/alice/other-project</root></workspace_roots><permission_profile type="managed"><file_system type="restricted"><entry access="read"><special>:minimal</special></entry><entry access="write"><path>/Users/alice/project</path></entry><entry access="write"><path>/Users/alice/other-project</path></entry><entry access="deny" escalatable="false"><path>/Users/alice/project/private</path></entry><entry access="deny" escalatable="false"><path>/Users/alice/other-project/private</path></entry><entry access="deny" escalatable="false"><glob>/Users/alice/project/private/**</glob></entry><entry access="deny" escalatable="false"><glob>/Users/alice/other-project/private/**</glob></entry></file_system></permission_profile></filesystem>
</environment_context>

Managed requirements can impose the same kind of deny-read restriction:

[permissions.filesystem]
deny_read = [
  "/Users/alice/project/private",
  "/Users/alice/project/private/**",
]

The automatic approval review prompt also receives the parent turn's denied-read context, so review decisions can account for the active permission profile.

What Changed

• Render the effective filesystem profile in <environment_context>, including profile type, filesystem entries, workspace roots, and non-escalatable deny entries.
• Persist effective workspace_roots in TurnContextItem so resumed/replayed context does not have to bind :workspace_roots through legacy cwd fallback.
• Add explicit permission instructions that denied reads are policy restrictions, not escalation targets.
• Pass the parent turn's denied-read context into automatic approval reviews.
• Add targeted coverage for prompt rendering, workspace-root materialization, replay context, and review prompt context.
• Keep the prompt-context test expectations platform-aware so the same filesystem rendering assertions pass on Unix and Windows paths.

Testing

• just test -p codex-core context::environment_context::tests::serialize_environment_context_with_full_filesystem_profile
• just test -p codex-core context::environment_context::tests::turn_context_item_filesystem_uses_workspace_roots_instead_of_cwd
• just test -p codex-core context::permissions_instructions::permissions_instructions_tests::builds_permissions_from_profile_with_denied_reads
• just fix -p codex-core

I also attempted just test -p codex-core; the changed prompt-context tests passed, but the full local run did not complete cleanly in this sandboxed macOS environment due unrelated user-shell CODEX_SANDBOX* expectations and integration-test timeouts.

[viyatb-oai]

lgtm, my only concern is that someone can configure a bad profile that can balloon up the environment context unbounded.