app-server: dynamicTools are not inherited by subagents spawned with fork_turns: "none"

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

26.831.21537

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

When a Codex app-server thread is started with custom dynamicTools, the main agent can use those tools, but subagents spawned with fork_turns: "none" do not receive them.

The child still receives the normal Codex tools and configured MCP servers, but the parent thread's dynamicTools are absent from the child’s callable tool inventory and from the child model request.

The same subagent receives the dynamic tools when spawned with fork_turns: "all".

This makes conversation-history isolation also act as tool-capability isolation. As a result, applications cannot create a clean, context-efficient subagent that has the same tools as its parent.

What steps can reproduce the bug?

1. Start Codex app-server.

2. Create a thread with at least one custom dynamic tool in thread/start, for example:

   {
     "dynamicTools": [
       {
         "name": "test_dynamic_tool",
         "description": "A test tool provided by the app-server client.",
         "inputSchema": {
           "type": "object",
           "properties": {}
         }
       }
     ]
   }
   
   

3. Start a parent-agent turn and ask it to call test_dynamic_tool. The parent can see and call the tool successfully.

4. Ask the parent to spawn a bounded subagent with:

   {
        "fork_turns": "none"
   }
   

Give the child a task that requires calling test_dynamic_tool.

5. Observe that the child cannot see or call the tool. If the child model request or callable-tool registry is inspected, test_dynamic_tool is absent.
6. Repeat the same test with:

   {
        "fork_turns": "all"
   }
   

7. Observe that the dynamic tool is now present in the child model request and can be called by the child.

In our integration, this reproduces consistently:

• fork_turns: "none": parent dynamicTools are absent.
• fork_turns: "all": parent dynamicTools are present.
• Configured MCP servers are inherited in both cases, so the behavior appears specific to dynamicTools.

What is the expected behavior?

A spawned subagent should inherit the parent thread's callable dynamicTools regardless of whether conversation turns are copied.

fork_turns should control conversation-history inheritance, not silently change the child’s tool registry.

Ideally:

• fork_turns: "none" creates a clean child with the same allowed tools as the parent.
• The inherited authorization is equal to or narrower than the parent’s authorization.
• fork_turns: "all" additionally copies the parent conversation, but does not provide a different tool set.

If automatic inheritance is not intended, app-server should expose an explicit option for inheriting or supplying the parent’s dynamic tools when spawning a subagent.

Additional information

Reproduced with Codex app-server 0.153.0 on macOS.

Our application supplies server-handled tools through dynamicTools on thread/start.

The issue appears limited to dynamically supplied tools:

• Core Codex tools remain available to the child.
• Configured MCP servers are inherited with both fork_turns: "none" and fork_turns: "all".
• dynamicTools are inherited only with fork_turns: "all".

Using fork_turns: "all" is not an equivalent workaround because it copies the complete parent conversation, uses substantially more context, and inherits the parent model and reasoning configuration. Full-history forks also do not allow the same child model/reasoning overrides available to clean forks.

Prompts, skills, and AGENTS.md instructions cannot solve this because the missing tools are not included in the child’s callable tool definitions.

Start at the app-server thread/start handling and the subagent fork path, comparing how dynamicTools are carried into children for fork_turns "none" versus "all". Reproduce the request with a custom dynamic tool and inspect the child callable-tool registry and model request; done means clean forks inherit the parent dynamicTools without inheriting conversation history.