Skip to content

Allow launchThread to pass Codex approvalPolicy and sandboxPolicy (e.g. approval "never" + workspace-write) #21138

Closed as not planned

Description

@shelomo

Context: T3 0.1.1-nightly.20261018.3285. orchestration.launchThread accepts runtimeMode/interactionMode but no
approvalPolicy or sandboxPolicy, and RuntimePolicyV2.resolve sets only runtimeMode, interactionMode and cwd.
Runtime modes map to fixed Codex settings:

  • approval-required: untrusted / user / read-only
  • auto-accept-edits: on-request / user / workspace-write
  • auto: on-request / auto_review / workspace-write
  • full-access: never / user / full access

Problem: Hosts that enforce /etc/codex/requirements.toml with allowed_approval_policies = ["never"] and
allowed_sandbox_modes = ["read-only","workspace-write"] (headless, fail-closed bot runners) cannot start any T3 turn
except full-access, which defeats the sandbox. Every non-full-access mode fails with "provider could not start this turn".

Ask: either (a) accept optional approvalPolicy and sandboxPolicy in launchThread input (or a server setting) and pass
them through to the Codex thread, validated against requirements.toml; or (b) add a runtime mode such as
"sandboxed-unattended" = approval never + workspace-write.

Expected: a command blocked by the sandbox fails back to the model and is never re-run unsandboxed.

Activity

  1. juliusmarminge commented on Oct 18, 2026

    @juliusmarminge
    Member

    Note

    Grok responding on behalf of Julius.

    Thanks for the detailed write-up. This is a feature request, so it belongs in Ideas; the closely related idea #6976 (Codex sessions inheriting configured permission profiles) already covers managed Codex policies rejecting T3's fixed runtime-mode settings, so adding your headless runner case there would help too.

  2. t3dotgg commented on Oct 21, 2026

    @t3dotgg
    Member

    Note

    🤖 Claude Opus 5.5 responding on behalf of Theo

    Thanks for the idea. Feature requests and proposals belong in Ideas discussions, where others can find and vote on them and maintainers track direction, so we close them here (see CONTRIBUTING.md). If this still matters to you, please post it there and link this issue.

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

    enhancementRequested improvement or new capability.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions