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

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

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

Visibility: public

Requested revision: 74f95dfc4fea9670eee202adb1ba4b3dc34142ed

Requested commit: 74f95dfc4fea9670eee202adb1ba4b3dc34142ed

Commit: 74f95dfc4fea9670eee202adb1ba4b3dc34142ed

Tree: 8b240b08b9fee3c21486027291a1c99dd9a8f382

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

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

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