Remove unintended whitespace from spawn agent tool descriptions

Description

The generated spawn_agent tool descriptions contain unintended leading whitespace because indentation inside several raw format! strings in multi_agents_spec.rs is preserved in the serialized description.

For example, the current v2 description can be serialized with leading indentation before the model guidance and Spawns an agent to work on the specified task.

The current HTTP request has such parts in the tool description

"\n        Available model overrides (optional; inherited parent model is preferred):\n- `gpt-5.6-sol`: Latest frontier"

"ow, medium (default), high, xhigh.\n        Spawns an agent to work on the specified task. If your current task is `/root/task1` and you spawn_agent with task_name \"task_3\" the agent will have ..."

Notice \n in the beginning and in the middle.

Full json description field

"\n Available model overrides (optional; inherited parent model is preferred):\n- gpt-5.6-sol: Latest frontier agentic coding model. Reasoning efforts: low (default), medium, high, xhigh, max, ultra. Service tiers: priority.\n- gpt-5.6-terra: Balanced agentic coding model for everyday work. Reasoning efforts: low, medium (default), high, xhigh, max, ultra. Service tiers: priority.\n- gpt-5.6-luna: Fast and affordable agentic coding model. Reasoning efforts: low, medium (default), high, xhigh, max. Service tiers: priority.\n- gpt-5.5: Frontier model for complex coding, research, and real-world work. Reasoning efforts: low, medium (default), high, xhigh. Service tiers: priority.\n- gpt-5.2: Optimized for professional work and long-running agents. Reasoning efforts: low, medium (default), high, xhigh.\n Spawns an agent to work on the specified task. If your current task is /root/task1and you spawn_agent with task_name \"task_3\" the agent will have canonical task name/root/task1/task_3.\nYou are then able to refer to this agent as task_3or/root/task1/task_3interchangeably. However an agent/root/task2/task_3would only be able to communicate with this agent via its canonical name/root/task1/task_3.\nThe spawned agent will have the same tools as you and the ability to spawn its own subagents.\n\nOnly call this tool for a concrete, bounded subtask that can run independently alongside useful local work; otherwise continue locally.\nIt will be able to send you and other running agents messages, and its final answer will be provided to you when it finishes.\nThe new agent's canonical task name will be provided to it along with the message.\n\nNote that passing fork_turns="none"will not pass any surrounding context to the spawned subagent, which may cause the agent to lack the context it needs to complete its task, whereasfork_turns="all" will provide the subagent with all surrounding context."

Rendering the line breaks to new lines to show it better:

        Available model overrides (optional; inherited parent model is preferred):
- `gpt-5.6-sol`: Latest frontier agentic coding model. Reasoning efforts: low (default), medium, high, xhigh, max, ultra. Service tiers: priority.
- `gpt-5.6-terra`: Balanced agentic coding model for everyday work. Reasoning efforts: low, medium (default), high, xhigh, max, ultra. Service tiers: priority.
- `gpt-5.6-luna`: Fast and affordable agentic coding model. Reasoning efforts: low, medium (default), high, xhigh, max. Service tiers: priority.
- `gpt-5.5`: Frontier model for complex coding, research, and real-world work. Reasoning efforts: low, medium (default), high, xhigh. Service tiers: priority.
- `gpt-5.2`: Optimized for professional work and long-running agents. Reasoning efforts: low, medium (default), high, xhigh.
        Spawns an agent to work on the specified task. If your current task is `/root/task1` and you spawn_agent with task_name \"task_3\" the agent will have canonical task name `/root/task1/task_3`.
You are then able to refer to this agent as `task_3` or `/root/task1/task_3` interchangeably. However an agent `/root/task2/task_3` would only be able to communicate with this agent via its canonical name `/root/task1/task_3`.
The spawned agent will have the same tools as you and the ability to spawn its own subagents.

Only call this tool for a concrete, bounded subtask that can run independently alongside useful local work; otherwise continue locally.
It will be able to send you and other running agents messages, and its final answer will be provided to you when it finishes.
The new agent's canonical task name will be provided to it along with the message.

Note that passing `fork_turns=\"none\"` will not pass any surrounding context to the spawned subagent, which may cause the agent to lack the context it needs to complete its task, whereas `fork_turns=\"all\"` will provide the subagent with all surrounding context.

Fix

I prepared a small patch that:

• removes the unintended indentation and leading newlines from both spawn-agent description variants
• avoids introducing a leading newline when optional model guidance is absent
• cleans up the same whitespace behavior around optional usage hints

You can browse it here:
https://github.com/atacan/codex/pull/1/changes

Expected behavior

Generated tool descriptions should begin directly with their intended content and should not depend on Rust source indentation.

Start in multi_agents_spec.rs, where the raw format! strings for the spawn_agent description variants are assembled. Inspect both variants and the optional model guidance and usage hints; done means serialized descriptions begin directly with their intended content without indentation or leading newlines.