Eric Traut 53a1f4c29e TUI: route elicitation responses to request thread (#23241) ...

## Why

Fixes #21894.

When the TUI handles an MCP elicitation, the request payload already
includes the thread that generated the elicitation.
`ChatWidget::handle_elicitation_request_now` was ignoring that value and
using the currently visible chat thread instead. In a multi-session TUI,
that can send `resolve_elicitation` to an older visible thread rather
than the session that owns the pending elicitation, producing
`elicitation request not found` and leaving the prompt unresolved.

## What changed

- Parse `McpServerElicitationRequestParams.thread_id` in the ChatWidget
elicitation handler and use it for app-link, form, fallback approval,
and auto-decline resolution paths.
- Keep the existing visible-thread fallback only for malformed request
payloads with an invalid thread id.
- Update the invalid URL elicitation regression test so the visible
thread and request thread intentionally differ.

2026-05-18 11:33:13 -07:00

..

frames

Rename tui_app_server to tui (#16104)

2026-03-28 11:23:07 -06:00

src

TUI: route elicitation responses to request thread (#23241)

2026-05-18 11:33:13 -07:00

tests

Simplify TUI startup test coverage (#22573)

2026-05-13 18:16:54 -07:00

BUILD.bazel

Remove CODEX_RS_SSE_FIXTURE test hook (#22413)

2026-05-13 03:08:01 +00:00

Cargo.toml

Trim TUI legacy core helper usage (#22695)

2026-05-14 16:54:59 -07:00

prompt_for_init_command.md

Rename tui_app_server to tui (#16104)

2026-03-28 11:23:07 -06:00

styles.md

Rename tui_app_server to tui (#16104)

2026-03-28 11:23:07 -06:00

tooltips.txt

feat(tui): add configurable keymap support (#18593)

2026-04-28 12:52:25 -03:00