[Bug] A spawned sub-agent inherits the parent model identity sentence in its instructions #5217

Client or integration

Codex App (also reproduced through the Codex CLI app-server)

Area

Catalog / models

Summary

When a sub-agent is spawned with a model different from its parent, the worker's instructions still carry the parent model's identity sentence. Routing itself is correct; only the prompt text is stale.

• Parent bai/deepseek-v4.1-flash -> worker gpt-6-astra: the worker's developer instruction block starts with the same sentence as the parent session's instructions text and contains You are a coding agent powered by the deepseek-v4.1-flash. If asked which model you are, identify as deepseek-v4.1-flash. ...
• Reverse direction (parent gpt-6-astra -> worker bai/deepseek-v4.1-flash): the worker's instruction block contains You are Codex, an agent based on GPT-6.

Expected: the identity sentence in a worker's instructions matches the worker's destination model.

Observable side effect: asking the worker which model it is returns an answer that contradicts turn_context.payload.model. A worker actually running gpt-6-astra answered gpt-6, because both sentences are present in its prompt.

Reproduction

1. ocx start --port 10100, with Codex App/CLI pointed at this proxy.
2. Have one routed model and one native model in the same catalog (for example bai/deepseek-v4.1-flash and gpt-6-astra).
3. Run a session on the routed model and call spawn_agent with model="gpt-6-astra" and reasoning_effort="medium". Keep the worker prompt to Reply ACK only.
4. Inspect the worker's instructions and the request the client sent.

Result: the worker's developer instruction block names the parent model while its own identity block names the child model, and the two disagree.

Version

2.59.0

Operating system

macOS 26.6.2

Provider and model

bai/deepseek-v4.1-flash (worker) / gpt-6-astra (both directions)
Codex CLI 0.155.0-alpha.9

Logs or error output

Client request for the worker, captured on the wire before it reached the proxy (values shortened):

model = gpt-6-astra
input[0].role = developer
input[0].content[0].text =
"You are a coding agent powered by the deepseek-v4.1-flash. If asked which model you are,
identify as deepseek-v4.1-flash. ... You and the user share one workspace, ..."
input[1] (model_switch block) =
"You are Codex, an agent based on GPT-6. ..."

Session metadata for the same request:
turn_context.payload.model = gpt-6-astra (routing is correct)
worker self-report = "gpt-6"

Screenshots and supporting files

(none)

Redacted configuration

Reproducible with one routed provider and one native model. Not provider-specific.

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.

Additional analysis

The destination model name is written into the prompt at catalog-build time. The call sites are identifyRoutedModel(e.base_instructions, modelName) in src/codex/catalog/derive-entry.ts and the alias-row handling in src/codex/catalog/metadata.ts. That sentence is then stored as session instructions, and because Codex reuses the parent session's instruction block when spawning a worker, a worker running a different model inherits it verbatim.

There is also no request-time repair on the Responses path. identifyRoutedModel is applied in the chat-family adapters (src/adapters/openai-chat/messages.ts, anthropic/google/kiro/command-code) but not in the Responses passthrough, so the native wording Codex injects on every request reaches routed destinations unchanged as well.

Two changes cover both directions: emit a model-neutral catalog prompt (for example You are a coding agent.), and at request time rewrite only this proxy's own generated identity sentence using the destination wire model. A native destination should keep Codex's original wording, and user/tool messages, fenced code, the remaining instruction text, model selection and reasoning settings should not change. Retained catalog rows merged from disk need the same repair. This direction was verified locally against the two call sites above.