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

[View on GitCafe](https://git.cafe/stienswout/t3code/commit/13ba775496ff2907054fbb96e413a74e48793067)

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

Visibility: public

Requested revision: 13ba775496ff2907054fbb96e413a74e48793067

Requested commit: 13ba775496ff2907054fbb96e413a74e48793067

Commit: 13ba775496ff2907054fbb96e413a74e48793067

Tree: 3cffe8cd76348a720842b67dda0b2b9b1937829b

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

- [58ffe9cfef5860bbceb6369e50831540814ef561](https://git.cafe/stienswout/t3code/commit/58ffe9cfef5860bbceb6369e50831540814ef561?format=markdown)

[Source at this commit](https://git.cafe/stienswout/t3code/tree/13ba775496ff2907054fbb96e413a74e48793067?format=markdown)
