followup_task resets a full-access subagent to read-only/on-request

What version of the Codex App are you using (From “About Codex” dialog)?

Codex App 26.818.41509, build 6962

Bundled CLI:

codex-cli 0.149.0-alpha.4.1

What subscription do you have?

ChatGPT Pro ($200/month)

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

A subagent initially inherits the parent thread's Full Access permission mode correctly. When the same subagent receives a later task through followup_task, its next turn is silently changed to:

approval_policy = on-request
sandbox_policy = read-only
permission_profile = managed/restricted

The parent remains configured as:

approval_policy = never
sandbox_policy = danger-full-access
permission_profile = disabled

As a result, the resumed subagent starts requesting permission or cannot perform operations that were allowed during its initial turn.

This was not caused by a custom agent profile. The affected child was spawned without a custom role, and no agent-specific sandbox or approval override was configured.

The user-level configuration was:

approval_policy = "never"
sandbox_mode = "danger-full-access"

Session identifiers

Parent session ID:
01a01582-fcb9-7870-98f3-fe146eea0504

Affected child thread ID:
01a03037-2a04-7df3-b40d-1878a91e5902

The session identifiers are included to support internal investigation. All prompts, task names, workspace paths, filenames, hostnames, commands, and application data below have been redacted.

Sanitized rollout evidence

The child initially inherited the parent permissions correctly:

{
  "timestamp": "2026-08-23T20:02:00.071Z",
  "approval_policy": "never",
  "sandbox_policy": {
    "type": "danger-full-access"
  },
  "permission_profile": {
    "type": "disabled"
  },
  "active_permission_profile": {
    "id": ":danger-full-access"
  },
  "model": "gpt-5.6-sol"
}

The parent still had the same effective permissions immediately before the follow-up:

{
  "approval_policy": "never",
  "sandbox_policy": {
    "type": "danger-full-access"
  },
  "permission_profile": {
    "type": "disabled"
  },
  "active_permission_profile": {
    "id": ":danger-full-access"
  },
  "model": "gpt-5.6-sol"
}

The parent invoked followup_task for the existing child:

{
  "timestamp": "2026-08-23T20:15:21.938Z",
  "type": "function_call",
  "name": "followup_task",
  "arguments": {
    "target": "01a03037-2a04-7df3-b40d-1878a91e5902",
    "message": "<redacted-follow-up-task>"
  }
}

The follow-up turn started successfully, but its permissions were silently replaced:

{
  "timestamp": "2026-08-23T20:15:23.149Z",
  "approval_policy": "on-request",
  "sandbox_policy": {
    "type": "read-only"
  },
  "permission_profile": {
    "type": "managed",
    "file_system": {
      "type": "restricted",
      "entries": [
        {
          "path": {
            "type": "special",
            "value": {
              "kind": "root"
            }
          },
          "access": "read"
        }
      ]
    },
    "network": "restricted"
  },
  "active_permission_profile": null,
  "model": "gpt-5.6-sol"
}

The developer message injected into the follow-up turn also stated:

Filesystem sandboxing defines which files can be read or written.
sandbox_mode is read-only.
Network access is restricted.

No user permission change occurred between these events.

What steps can reproduce the bug?

The evidence above comes from an observed Codex App workload. I have not yet reduced it to a separate isolated test session.

The observed sequence was:

1. Start a Codex App thread with Full Access selected.
2. Confirm that the parent uses approval_policy=never and sandbox_mode=danger-full-access.
3. Spawn a subagent with spawn_agent.
4. Confirm that the child's initial turn_context also contains never and danger-full-access.
5. Send another task to the same child using followup_task.
6. Inspect the new child turn_context.
7. Observe that it has changed to on-request, read-only, and a managed restricted permission profile, although the parent remains in Full Access mode.

A minimal probe could ask a child to report its effective permissions, then use followup_task to ask it to report them again.

What is the expected behavior?

followup_task should preserve the child thread's resolved sandbox and approval configuration.

In this case, the follow-up turn should remain:

approval_policy = never
sandbox_policy = danger-full-access
permission_profile = disabled

If the runtime cannot preserve the existing configuration, it should fail explicitly instead of silently replacing the permission mode.

This matches the documented behavior that subagents inherit the permission mode selected for the parent turn and that live sandbox and approval overrides are reapplied to children:

https://learn.chatgpt.com/docs/agent-configuration/subagents#approvals-and-sandbox-controls

Additional information

Related reports:

• #33314 states that followup_task should preserve the child's sandbox and permissions across later turns.
• #23324 reports subagent approval behavior not following the parent policy.
• #12713 is an older, inverse inheritance bug in which spawn_agent forced approval_policy=never.

This report is narrower: the initial spawn_agent inheritance is correct, but the same child's next turn, triggered by followup_task, is silently changed from Full Access to read-only/on-request.

I can provide additional sanitized rollout excerpts if needed. The complete unredacted task content should not be posted publicly.

Start by reproducing the issue with spawn_agent and followup_task, then inspect the child turn_context before and after the follow-up. Trace how the child's resolved approval and sandbox configuration is rebuilt; done means the follow-up preserves Full Access settings or fails explicitly rather than silently switching to read-only/on-request.