# feat\(orchestration-v2\): carry approval options and app names to the client \(\#8058\) · pingdotgg/t3code

[View on GitCafe](https://git.cafe/pingdotgg/t3code/commit/1c0bb7f4850c515a6fbaee0145557a40861e4f8c)

Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code)

Visibility: public

Requested revision: 1c0bb7f4850c515a6fbaee0145557a40861e4f8c

Requested commit: 1c0bb7f4850c515a6fbaee0145557a40861e4f8c

Commit: 1c0bb7f4850c515a6fbaee0145557a40861e4f8c

Tree: a273c2ff8e910a92e4ed92e2ff9a788839f79ca0

Author: Julius Marminge

Committer: Julius Marminge

## Message

```
feat(orchestration-v2): carry approval options and app names to the client (#8058)

Round 10 ported main's option-driven approval buttons, but v2 runtime
requests had no way to deliver the data — every approval rendered the
default button set, MCP app names never showed, and worse, the Codex
app-server's mcpServer/elicitation/request went entirely unhandled on the
v2 adapter, so ChatGPT-app access requests could never be answered.

The v2 approval_request turn item now carries optional appName and
options, the client derivation passes them into ThreadPendingApproval,
and CodexAdapterV2 handles mcpServer/elicitation/request end to end:
unsupported shapes decline immediately (mirroring the v1 runtime), and
supported ones surface a mcp-elicitation approval built from the shared
describeMcpElicitation/toMcpElicitationResponse helpers, so the persist
tiers (session / always) advertise exactly the choices the elicitation
can express.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

```

## Parents

- [d14f023f88f48d5213e98b4c98b2c679c00a1001](https://git.cafe/pingdotgg/t3code/commit/d14f023f88f48d5213e98b4c98b2c679c00a1001?format=markdown)

[Source at this commit](https://git.cafe/pingdotgg/t3code/tree/1c0bb7f4850c515a6fbaee0145557a40861e4f8c?format=markdown)