Preserve namespaces on custom tool calls

[nhamidi-oai]

Summary

• Preserve the optional namespace on custom tool calls during response deserialization and app-server replay.
• Use the namespaced tool identifier for streaming argument handling and tool dispatch.
• Regenerate app-server protocol schemas.
• Add regression tests covering namespace serialization and routing.

Testing

• Ran affected protocol and app-server test suites.
• Ran the full core test suite; two load-sensitive timing tests passed when rerun individually.
• Ran Clippy and formatting checks.
• Verified with a local end-to-end app-server replay that the namespace is preserved through the complete request/response flow.

[github-actions]

All contributors have signed the CLA ✍️ ✅
_{Posted by the CLA Assistant Lite bot.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 49c6ad0ac7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 49c6ad0ac7

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[nhamidi-oai]

I have read the CLA Document and I hereby sign the CLA

[rpelevin]

I would treat the namespace as part of the tool-call identity, not as replay metadata.

The risky failure mode here is not just that a custom call loses a display field. It is that two callable surfaces can share a name while meaning different things, and the agent can deserialize, replay, or route the call using the unqualified name. If that happens, a previously recorded custom call can be dispatched to the wrong tool surface even though the visible name still looks correct.

The regression I would want is end to end:

1. stream a custom tool call with a namespace and a name that also exists in another namespace;
2. preserve the namespace through response-item deserialization;
3. persist it into history;
4. resume or replay through the app-server path;
5. route streaming arguments using the fully qualified identifier;
6. dispatch only to the namespaced tool, never to the same plain name in a different namespace;
7. assert the completed item and any replayed event still carry the namespace.

The unit router test is useful, but it is not the acceptance boundary. The acceptance boundary is the live agent path: stream in, history out, replay back in, dispatch out. If any layer normalizes back to name-only, the test should fail before a tool call can be invoked.

That also gives the protocol a clean invariant: name is not globally authoritative when namespace exists. The executable action identity is namespace plus name, and every bridge that stores or rehydrates the response item has to preserve that pair before dispatch.

Boundary: architecture and regression-test feedback only; no claim about using this project, running this branch, validating implementation behavior, implementation correctness, merge readiness, security review, production readiness, partnership, customer interest, official alignment, OpenAI usage, Codex usage, conformance certification, or Neura usage.