[Feature]: Allow Codex sessions to inherit configured permission profiles

[robertmsale]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

apps/web

Problem or use case

T3 Code's native Codex integration appears to translate its runtime-mode choice into hard-coded Codex sandbox_mode and approval_policy values. This prevents users from using a named/default permission profile already configured in Codex.

For example, my Codex configuration defines a local-dev permission profile and sets it as the default:

default_permissions = "local-dev"

[permissions.local-dev]
sandbox_mode = "workspace-write"
approval_policy = "on-request"

[permissions.local-dev]
description = "Workspace development with network and Skizzles tooling access"
extends = ":workspace"

[permissions.local-dev.filesystem]
"/Users/robertsale/.codex/hooks" = "write"
"/Users/robertsale/.codex/scripts" = "write"
"/Users/robertsale/.codex/bin" = "write"
"/Users/robertsale/.codex/skills" = "write"
"/Users/robertsale/.codex/skizzles" = "write"
"/Users/robertsale/Library/Application Support/OpenAI/codex-container-lab" = "write"
"/Users/robertsale/.docker/buildx" = "write"

[permissions.local-dev.network]
enabled = true

[permissions.local-dev.network.unix_sockets]
"/Users/robertsale/.orbstack/run/docker.sock" = "allow"

When Codex is launched directly, this profile provides the intended development permissions. When T3 Code starts the Codex app-server session, it appears to select its own runtime mode instead, so the configured Codex default is not authoritative.

This is especially problematic for users with managed Codex policies: T3 can send combinations such as approval_policy = "never" and sandbox_mode = "danger-full-access" that are rejected by Codex policy, as seen in #4292.

Proposed solution

Add a Codex-specific runtime option such as Use Codex configured default (or Inherit Codex configuration).

When selected, T3 Code should omit its sandbox_mode and approval_policy overrides from thread/session startup and let Codex resolve default_permissions, named permission profiles in ~/.codex/config.toml, managed-policy restrictions, and project/workspace-specific permission configuration.

This should be an explicit Codex-provider option, not a new T3-specific permission schema. Existing T3 modes such as Full access, Auto-accept edits, and Supervised can remain unchanged.

If the Codex app-server protocol requires an explicit profile name, support an optional named profile selector; otherwise omission/inheritance is the smallest useful implementation.

Why this matters

Users who have invested in Codex permission profiles currently have to choose between T3 Code and their configured Codex safety/development policy. T3's generic modes cannot express useful least-privilege setups such as allowing normal development commands and workspace edits while retaining approval prompts for everything else.

It also avoids T3 accidentally fighting organization-managed Codex policies or producing misleading startup errors when its hard-coded mode is disallowed.

Smallest useful scope

1. Add a Codex-only inherit configured permissions option.
2. Do not send permission/sandbox overrides when it is selected.
3. Preserve the current defaults and behavior of existing T3 runtime modes.
4. Add an integration test asserting that the Codex adapter omits those overrides.
5. Surface a clear effective-mode label in the UI (for example, Codex config).
6. A profile-management UI, cross-provider permission abstraction, or granular T3 rule language is not required for the first version.

Alternatives considered

• Editing ~/.codex/config.toml to make one of T3's generic modes approximate the desired behavior: fragile and can affect Codex Desktop/CLI globally.
• Using Full access: too broad and may violate managed policy. I particularly do not wish to do this.
• Using Supervised: too restrictive for routine local development and does not honor custom allowlists.
• Asking users to maintain a second T3-specific permission configuration: duplicates Codex's existing authority and will drift.

Risks or tradeoffs

• Omitting overrides means behavior depends on the user's Codex configuration, so T3 should label this clearly.
• Existing T3 modes should remain deterministic and unaffected.
• The adapter should capability-detect older Codex app-server versions and provide a clear error if inheritance is unavailable.

Examples or references

Related: #4292 (Codex startup failure when T3's hard-coded approval/sandbox combination conflicts with managed policy); #4916 (global default runtime mode). Codex configuration reference: https://developers.openai.com/codex/config-reference/

Contribution

• I would be open to helping implement this.

[ar-jan]

This would be a very helpful addition.

[robertmsale]

I created a branch that resolves this issue by detecting what model provider is selected and, if it's Codex, offers a passthrough permission policy.

https://github.com/robertmsale/t3code/tree/t3code/codex-inherited-permissions

It covers certain situations like switching from Codex to Claude, transforming the permission profile to one that's compatible with Claude. I haven't opened a PR yet since this is more of a "feature" than a show-stopper, it might be worth discussing other options. I think passthrough is probably the easiest way to handle it but anybody else have any ideas? I'm not familiar with all the providers so I made a special "if codex then passthrough unlocked" mode. Maybe it could be simplified to all providers? Or another solution exists? :)