Emit Trusted MCP App Identity on Tool-Call Items by martinauyeung-oai · Pull Request #27132 · openai/codex

martinauyeung-oai · 2026-06-09T06:17:14Z

Summary

Add optional appContext to app-server MCP tool-call items with trusted connectorId, linkId, and mcpAppResourceUri metadata.
Preserve that context across tool-call events, persisted history, reconnects, and thread resume.
Keep the deprecated top-level mcpAppResourceUri temporarily for client migration.

The consumer contract is { appContext: { connectorId, linkId, mcpAppResourceUri }, tool }.

Validation

Full GitHub Actions suite passes, including CLA, Bazel tests, clippy, release builds, and argument-comment lint.

github-actions · 2026-06-09T06:17:26Z

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

martinauyeung-oai · 2026-06-09T07:52:38Z

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

martinauyeung-oai · 2026-06-11T21:54:16Z

recheck

martinauyeung-oai · 2026-06-17T21:41:42Z

recheck

martinauyeung-oai · 2026-06-17T23:04:12Z

Message from Martin's Codex agent: @mzeng-openai The PR was rebased onto current main to pick up the expired macOS SDK pin fix. git range-diff shows all nine PR commits are patch-identical, and current-head CI is green. Could you re-approve the rebased head when convenient?

owenlin0 · 2026-06-17T23:33:35Z

        tool: String,
        status: McpToolCallStatus,
        arguments: JsonValue,
+        connector_id: Option<String>,


instead of defining these as top-level fields, what do you think of this instead:

McpToolCall { ... app_context: Option<McpToolCallAppContext>, } pub struct McpToolCallAppContext { pub id: String, pub link_id: Option<String>, }

It has these benefits IMO:

It keeps the generic MCP item fields generic. Top-level connector_id and link_id fields seem slightly misleading since they are only populated when using our first party codex_apps MCP server.

It uses app-server’s public vocabulary: the API already has app/list and AppInfo { id, ... }, where the “connector id” is already exposed to clients as the app id.

It lets clients correlate with app/list.

Message from Martin's Codex agent: This is technically coherent and aligns well with app/list/AppInfo.id. The one blocker is that the PR currently documents an external consuming-backend contract of { connectorId, linkId, tool }; nesting it as appContext: { id, linkId } changes that wire contract, and this repo cannot verify whether that consumer can migrate. I’m confirming that product/API decision with Martin before changing the shape. I’ll update this thread once resolved.

haha rogue bot. please ignore. Let me look at the consumer side code more carefully. I considered this previously but was told it might require a lot of code changes on the consumer end, but I do like this solution a lot more.

so my initial thought process was to also bake mcp_app_resource_uri into the McpToolCallAppContext which would also cause a lot of consumer side changes. reason being that thought it'd be better to keep it flat instead of having the app context with connectorID and linkID but mcp_app_resource_uri separated and causing additional confusion, as well as rollout safety & efficiency (timeline constraint)

I don't mind creating a follow-up PR that adds mcp_app_resource_uri to McpToolCallAppContext separately and keeps the code cleaner. WDYT?

owenlin0 · 2026-06-17T23:41:13Z

    }

    fn handle_mcp_tool_call_begin(&mut self, payload: &McpToolCallBeginEvent) {
+        // The canonical started item carries app identity that this deprecated event cannot.


let's avoid this complexity - we can just add the new fields to McpToolCallBeginEvent as well, and we won't need this

owenlin0 · 2026-06-17T23:41:24Z

    }

+    #[test]
+    fn active_turn_snapshot_preserves_started_mcp_connector_id() {


once we do that, we can delete this test

owenlin0 · 2026-06-17T23:42:30Z

    }

+    #[test]
+    fn mcp_tool_call_end_event_defaults_missing_connector_id() {


hm, is this test useful?

owenlin0 · 2026-06-18T04:07:36Z

+pub struct McpToolCallAppContext {
+    pub connector_id: String,
+    pub link_id: Option<String>,
+    pub mcp_app_resource_uri: Option<String>,


nit: would we be able to call this just resource_uri here? I'm guessing mcp_app_ is redundant at this point?

i think we should change this to rendering_uri but may require some downstream consumer changes. I'll add this as a follow-up PR

owenlin0 · 2026-06-18T04:11:29Z

            }
-            codex_protocol::items::TurnItem::Sleep(_) => {
+            codex_protocol::items::TurnItem::Sleep(_)
+            | codex_protocol::items::TurnItem::McpToolCall(_) => {


I think we can revert this? We should switch thread_history.rs to turn items, similar to rollout files, but can be done as a separate PR. I think as is, the ThreadHistoryBuilder would be handling MCP tool calls twice (from both the legacy Begin/End events and the ItemStarted/Completed events)

sg, i thought initially the swap would be a code clarity change, good callout.

owenlin0

two remaining comments but preapproving

martinauyeung-oai force-pushed the martinauyeung/mcp-app-identity-tool-call-items branch from dbd8742 to ec83a47 Compare June 9, 2026 07:36

github-actions Bot added a commit that referenced this pull request Jun 9, 2026

@martinauyeung-oai has signed the CLA in #27132

d119c04

martinauyeung-oai marked this pull request as ready for review June 9, 2026 08:10

martinauyeung-oai requested a review from a team as a code owner June 9, 2026 08:10

martinauyeung-oai self-assigned this Jun 10, 2026

martinauyeung-oai force-pushed the martinauyeung/mcp-app-identity-tool-call-items branch 3 times, most recently from 1341465 to d839e6b Compare June 11, 2026 21:54

mzeng-openai requested review from mzeng-openai and owenlin0 June 16, 2026 17:37

mzeng-openai approved these changes Jun 16, 2026

View reviewed changes

martinauyeung-oai force-pushed the martinauyeung/mcp-app-identity-tool-call-items branch 2 times, most recently from dc75728 to 579e9fc Compare June 17, 2026 20:49

martinauyeung-oai force-pushed the martinauyeung/mcp-app-identity-tool-call-items branch from 579e9fc to 70af95d Compare June 17, 2026 22:46

martinauyeung-oai requested a review from mzeng-openai June 17, 2026 22:46

martinauyeung-oai enabled auto-merge (squash) June 17, 2026 23:07

martinauyeung-oai disabled auto-merge June 17, 2026 23:17

owenlin0 reviewed Jun 17, 2026

View reviewed changes

martinauyeung-oai force-pushed the martinauyeung/mcp-app-identity-tool-call-items branch from 7b70871 to a42d762 Compare June 18, 2026 01:05

owenlin0 reviewed Jun 18, 2026

View reviewed changes

owenlin0 approved these changes Jun 18, 2026

View reviewed changes

martinauyeung-oai force-pushed the martinauyeung/mcp-app-identity-tool-call-items branch from 721b28e to d86d88a Compare June 18, 2026 20:13

martinauyeung-oai added 15 commits June 18, 2026 13:41

Emit trusted MCP app identity on tool-call items

7adcd63

Emit structured MCP app link identity

9e3f4c8

Preserve current MCP app identity across reconnects

475ec89

Use realistic link ID in MCP identity test

211fab3

Keep MCP identity fixture update focused

6069db5

Remove MCP link IDs from tool call items

b35a46a

Simplify MCP connector identity coverage

86884ef

Remove redundant MCP identity coverage

1f006ef

Restore link ID on MCP tool call items

522bbdc

Nest MCP app identity in app context

a9d5338

Duplicate MCP resource URI in app context

19c8d54

update comment location

30f23a4

Use connectorId in MCP app context

45def30

Fix MCP app context test fixtures

b546819

Address MCP app context review feedback

c56a747

martinauyeung-oai force-pushed the martinauyeung/mcp-app-identity-tool-call-items branch from d86d88a to c56a747 Compare June 18, 2026 20:42

martinauyeung-oai merged commit 765309d into main Jun 18, 2026
31 checks passed

martinauyeung-oai deleted the martinauyeung/mcp-app-identity-tool-call-items branch June 18, 2026 21:02

github-actions Bot locked and limited conversation to collaborators Jun 18, 2026

Conversation

martinauyeung-oai commented Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Validation

Uh oh!

github-actions Bot commented Jun 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

martinauyeung-oai commented Jun 9, 2026

Uh oh!

martinauyeung-oai commented Jun 11, 2026

Uh oh!

martinauyeung-oai commented Jun 17, 2026

Uh oh!

martinauyeung-oai commented Jun 17, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

owenlin0 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

martinauyeung-oai commented Jun 9, 2026 •

edited

Loading

github-actions Bot commented Jun 9, 2026 •

edited

Loading