Commit Graph
11 Commits
Author SHA1 Message Date
joeflorencio-openai 1d64085e67 Validate step settings against proposed permissions (#40647)
## Why

Model requirements must be evaluated against the permissions that will apply
after a settings update. Validating against the current profile can reject a
valid model-and-permission update or allow a later permission-only update to
invalidate the selected model.

## What changed

- Group model, reasoning, service-tier, personality, and approval inputs into
  `StepSettings`, with a single apply-and-validate path.
- Apply permission and environment changes before validating step settings, so
  auto-review requirements use the proposed effective permissions.
- Revalidate existing step settings when permission or environment changes alter
  their constraints, and commit the update only when the complete candidate is
  valid.

## Testing

Added unit and integration coverage for atomic model/permission updates,
permission-only revalidation, environment-derived constraints, and both
standalone and turn-start settings operations.

GitOrigin-RevId: f50dfbd300484a09acc51ee4607278f300ca1cd9
2026-08-25 17:27:04 +00:00
sayan-oai f580dd886f Enforce environment network policies for remote execution (#39980)
## Why

`EnvironmentConfig.network_policy` could describe attachment-owned traffic
restrictions, but core rejected every configured policy because execution did
not enforce it.

## What changed

- Resolve each remote environment's network policy for the selected command
  and apply it to the execution-scoped proxy.
- Compose owner rules with controller constraints and saved network decisions
  while preserving inherited domain and Unix-socket denials.
- Keep strict allowlists non-expandable, allow reviewable policies to use
  network approvals, and reject sandbox escalation that would bypass an owner
  policy.
- Reject policies for local execution, disabled managed enforcement, or a
  disabled controller proxy.

## Testing

Added coverage for policy composition, scoped remote proxy behavior, approval
and denial flows, offline execution, and unsupported environment authority.

GitOrigin-RevId: d9331f616df24de6cd13ed68196f0ff7b0ca4dd9
2026-08-21 17:29:41 +00:00
sayan-oai d75c85f651 Separate thread settings from environment configuration (#39597)
## Why

Environment-owned permission profiles and workspace roots must remain effective
without being persisted or restored as thread-owned settings.

## What changed

- Keep thread settings snapshots and restore data separate from the effective
  configuration supplied by the primary environment.
- Use resolved environment permissions, active profiles, workspace roots, and
  network policy when building turn context and session events.
- Preserve environment selections when agents are evicted, resumed, or spawned,
  and validate owner configuration when it becomes ready.
- Start memory initialization only after the primary environment is configured.

## Testing

- Extend remote-environment and multi-agent tests to cover settings persistence,
  owner permission profiles, workspace roots, spawning, eviction, and resume.

GitOrigin-RevId: d82f126981cd0190233020bbdd61d96c70558868
2026-08-20 05:29:12 +00:00
sayan-oai 392328ed5d Preserve owner-provided environment configuration (#39278)
## Why

Thread settings could replace an owner-provided environment configuration with
`FromThread`, allowing the thread to take ownership of that configuration.

## What changed

Reject environment settings updates that change an existing owner-provided
configuration to `FromThread`.

## Testing

Cover preview and turn settings updates for pending, ready, and failed
owner-provided environments.

GitOrigin-RevId: c516954819447ceb29e2ff9f29fe781ca101ae54
2026-08-18 20:49:36 +00:00
sayan-oai 4a7b51c560 Add network policy metadata to environment configuration (#39055)
## What changed

- Add `EnvironmentNetworkPolicy` as a serializable view of portable domain,
  Unix-socket, upstream-proxy, and local-binding restrictions without exposing
  controller-owned proxy runtime settings.
- Add an optional `network_policy` field to `EnvironmentConfig` and re-export
  the policy and related permission types through the core APIs.
- Reject owner-provided network policies during environment preview and
  readiness until runtime enforcement is implemented, while preserving the
  existing controller policy when the field is absent.

## Testing

- Cover rejection through both environment preview and readiness, including
  preservation of the existing environment selection.

GitOrigin-RevId: 80ad4cf4d4a45632daa7a823e6cf568eb0e8bb80
2026-08-17 19:22:45 +00:00
sayan-oai e38290846c Enforce environment-specific command policies (#38942)
## What changed

- Add an optional restrictive execution policy to `EnvironmentConfig` and merge it over the active command policy for shell execution and approval decisions.
- Reject environment policies that contain allow rules, so environment configuration can only tighten command access.
- Include the environment policy fingerprint in cached approval keys so policy changes require fresh session approvals.

## Testing

- Cover restrictions overriding saved prefix approvals, policy changes invalidating session approvals, and environment overlays remaining effective when model-specific prefix filtering is active.

GitOrigin-RevId: e94f877549ed5e0f577b8cb52f3c1872c58f029d
2026-08-17 04:37:50 +00:00
sayan-oai 6c108912ee Honor per-environment shell variable policies (#38902)
## What changed

- Carry `ShellEnvironmentPolicy` in each resolved `EnvironmentConfig` and use
  the selected turn environment's policy for shell commands, user shell tasks,
  and unified exec.
- Infer the policy from the thread configuration when an environment does not
  provide its own resolved configuration.
- Redact the policy from `EnvironmentConfig` debug output because it can contain
  explicit environment variable values.

## Testing

- Verify shell handlers and unified exec filter inherited variables according
  to the selected environment while preserving its explicit overrides.

GitOrigin-RevId: 9f6a52aa4af60e5f17251a0e1b11e1926b779055
2026-08-16 20:35:05 +00:00
sayan-oai 2ca575026c Support pending environment attachment configuration (#38684)
## Why

An environment connection can be available before its owner has supplied the
configuration for a particular thread attachment. Threads need to start without
blocking while ensuring turns do not use that attachment prematurely.

## What changed

- Accept `Pending` environment configuration and resolve each attachment only
  after both its shared executor connection and owner configuration are ready.
- Add a `Failed` configuration state and `environment_failed` callback so an
  owner can fail one thread's attachment without affecting other threads.
- Keep pending and failed attachments out of capability-root inspection and turn
  environments, and allow failed attachments to recover through a ready update.
- Apply owner configuration before waking a waiting turn so its permission
  profile, login-shell policy, capability roots, and tools are immediately
  consistent.

## Testing

Add an integration test covering non-blocking thread startup, independent ready
and failed callbacks, waiting-turn resumption, installed capability and tool
configuration, and recovery from failure.

GitOrigin-RevId: d587e2025d584c867d782d470b18bf5a1a27b76c
2026-08-15 01:39:04 +00:00
sayan-oai fdbab67c66 Carry environment config in turn selections (#38521)
## What changed

- Add `EnvironmentConfigState` to `TurnEnvironmentSelection` so each environment attachment can inherit thread configuration or carry ready configuration for its login-shell policy and selected capability roots.
- Apply ready configuration during thread creation and thread-settings updates while reusing the existing environment connection.
- Validate selection configuration before applying settings, rejecting unsupported pending state and invalid capability roots.

## Testing

- Cover attachment-scoped capability roots, ready configuration at thread startup and turn updates, and rejection of invalid selections without changing existing settings.

GitOrigin-RevId: 86cf8f2148fdaa746ea0dd12890ab7b1577d7587
2026-08-14 07:52:38 +00:00
sayan-oai 781445f7c6 Centralize thread environment selection state (#38423)
## What changed

- Make `ThreadEnvironments` the source of truth for live environment selections and use it when building configuration snapshots, permission profiles, per-turn configuration, and MCP refresh inputs.
- Keep settings previews side-effect free while applying accepted environment updates consistently to subsequent turns.
- Move `EnvironmentConfig` into `codex-protocol` so environment ownership no longer depends on a core-only type.

## Testing

- Cover environment previews and snapshots, accepted and rejected steer updates, and active-turn environment stability.

GitOrigin-RevId: 7bcf8fb5df1215f720e4e9c419541a51a871aa5e
2026-08-13 19:25:05 +00:00
sayan-oai b43de77679 Scope environment readiness config to thread attachments (#38067)
## Why

Threads that share an executor environment can require different capability roots and login-shell policies. Treating readiness configuration as executor-wide can expose one thread's settings to another.

## What changed

- Add `CodexThread::environment_ready` and `EnvironmentConfig` so hosts can install capability roots and login-shell policy for an exact thread, environment, and working-directory attachment.
- Validate attachment readiness updates, merge ready attachment roots with persisted thread roots, and refresh MCP capabilities when those roots change.
- Preserve installed environment policy across thread settings updates and child-thread inheritance while resetting it when the selected working directory changes.

## Testing

- Cover attachment config inheritance and reset behavior.
- Verify that threads sharing an executor retain independent model-visible capability roots and login-shell tool schemas across updates.

GitOrigin-RevId: 60e7a296b3e41b835b0413aa2837451e8a55c230
2026-08-11 19:58:10 +00:00