Update subagent docs and defaults

codex-rs/core/root_agent_prompt.md

@@ -10,7 +10,7 @@ Use subagents as follows:
 - Let subagents run independently. You do not need to keep generating output while they work; focus your own turns on planning, orchestration, and integrating results.
 - Use `subagent_send_message` to give a subagent follow-up instructions, send it short status updates or summaries, or interrupt and redirect it.
 - Use `subagent_await` when you need to wait for a particular subagent before continuing; you do not have to await every subagent you spawn, because they can also report progress and results to you via `subagent_send_message` and completions will be surfaced to you automatically.
-- When you see a `subagent_await` call/output injected into the transcript without you calling the tool, that came from the autosubmit path: the system drained the inbox (e.g., a subagent completion) while the root was idle and recorded a synthetic `subagent_await` so you can read and react without issuing the tool yourself.
+- When you see a `subagent_await` call/output injected into the transcript without you calling the tool, that came from the autosubmit path: the system drained the inbox (e.g., a subagent completion) while the root was idle and recorded a synthetic `subagent_await` so you can read and react without issuing the tool yourself (controlled by `subagent_root_inbox_autosubmit` in `config.toml`).
 - Use `subagent_logs` when you only need to inspect what a subagent has been doing recently, not to change its state.
 - Use `subagent_list`, `subagent_prune`, and `subagent_cancel` to keep the set of active subagents small and relevant.
 - When you spawn a subagent or start a watchdog and there’s nothing else useful to do, issue the tool call right away and say you’re waiting for results (or for the watchdog to start). If you can do other useful work in parallel, do that instead of stalling, and only await when necessary.

codex-rs/docs/protocol_v1.md

@@ -1,12 +1,12 @@
-Overview of Protocol Defined in [protocol.rs](../core/src/protocol.rs) and [agent.rs](../core/src/agent.rs).
+Overview of Protocol Defined in [protocol.rs](../protocol/src/protocol.rs) and the Codex engine in [codex.rs](../core/src/codex.rs).
 
 The goal of this document is to define terminology used in the system and explain the expected behavior of the system.
 
-NOTE: This document summarizes the protocol at a high level. The Rust types and enums in [protocol.rs](../core/src/protocol.rs) are the source of truth and may occasionally include additional fields or variants beyond what is covered here.
+NOTE: This document summarizes the protocol at a high level. The Rust types and enums in [protocol.rs](../protocol/src/protocol.rs) are the source of truth and may occasionally include additional fields or variants beyond what is covered here.
 
 ## Entities
 
-These are entities exit on the codex backend. The intent of this section is to establish vocabulary and construct a shared mental model for the `Codex` core system.
+These are entities that exist on the Codex backend. The intent of this section is to establish vocabulary and construct a shared mental model for the `Codex` core system.
 
 0. `Model`
    - In our case, this is the Responses REST API
@@ -48,7 +48,7 @@ Every participant in a session (the root UI thread plus each spawned/forked chil
 
 When a `Turn` completes, the `response_id` from the `Model`'s final `response.completed` message is stored in the `Session` state to resume the thread given the next `Op::UserInput`. The `response_id` is also returned in the `EventMsg::TurnComplete` to the UI, which can be used to fork the thread from an earlier point by providing it in the `Op::UserInput`.
 
-Since only 1 `Task` can be run at a time, for parallel tasks it is recommended that a single `Codex` be run for each thread of work.
+Each `Session` still runs at most one `Task` at a time. For parallel work, you can either run multiple Codex sessions or use subagents (via the `subagent_*` tools) to orchestrate multiple child sessions within a single daemon.
 
 ## Interface
 
@@ -66,7 +66,7 @@ Since only 1 `Task` can be run at a time, for parallel tasks it is recommended t
     - This enum is `non_exhaustive`; variants can be added at future dates
     - It should be expected that new `EventMsg` variants will be added over time to expose more detailed information about the model's actions.
 
-For complete documentation of the `Op` and `EventMsg` variants, refer to [protocol.rs](../core/src/protocol.rs). Some example payload types:
+For complete documentation of the `Op` and `EventMsg` variants, refer to [protocol.rs](../protocol/src/protocol.rs). Some example payload types:
 
 - `Op`
   - `Op::UserInput` – Any input from the user to kick off a `Task`

docs/config.md

@@ -386,7 +386,7 @@ When `false`, cross-agent messages arrive only via `subagent_await` tool results
 Controls whether the root agent automatically drains its inbox (and any child
 messages destined for agent `0`) at safe stopping points between model turns,
 and whether it may auto-start a follow-up turn based on those messages. When
-`true`:
+`true` (default):
 
 - At the end of each model turn for the root, Codex drains the root inbox and
   injects synthetic `subagent_await` call/output pairs—complete with