TUI interaction and rendering tests

fn test_path_display(path: &str) -> String

Purpose: This function turns a test path string into the display form used in assertions. It helps tests compare paths without depending on a developer's real machine layout.

Data flow: It takes a path written as a string, passes it to the shared test path builder, then asks that path how it should be shown as text. The result is a String ready for a test expectation.

Call relations: Tests use this when they need a stable path display value. It delegates the actual path construction to test_path_buf from the shared path test-support code, then only adds the final conversion to display text.

Call graph: 1 external calls (test_path_buf).

fn session_source_cli() -> T

Purpose: This function creates a test value meaning “the session came from the command line.” It is useful when tests need that value in whatever compatible legacy type they are checking.

Data flow: It starts with the app-server protocol value for a CLI session source. It sends that value through from_app_server_wire, which converts it through JSON into the caller's requested type. The caller receives that converted test value, or the test panics if the conversion no longer works.

Call relations: Telemetry-related tests call this when building session data. Rather than doing the conversion itself, it hands the protocol value to from_app_server_wire so the same compatibility check is used consistently.

Call graph: calls 1 internal fn (from_app_server_wire); called by 2 (test_session_telemetry, test_session_telemetry).

fn skill_scope_user() -> T

Purpose: This function creates a test value meaning “this skill belongs to the user scope.” It lets tests ask for that value in the legacy type they already use.

Data flow: It takes the app-server protocol's User skill-scope value, converts it through the shared JSON-based bridge, and returns the requested output type. If the protocol value cannot be represented as that type, the test fails immediately.

Call relations: This is a small named shortcut around from_app_server_wire. It exists so tests can clearly say they want the user skill scope without repeating protocol conversion details.

Call graph: calls 1 internal fn (from_app_server_wire).

fn skill_scope_repo() -> T

Purpose: This function creates a test value meaning “this skill belongs to the repository scope.” It keeps tests readable while still using the app-server protocol as the source of truth.

Data flow: It starts with the app-server protocol's Repo skill-scope value. It passes that value into from_app_server_wire, which serializes and deserializes it into the caller's requested type, then returns the converted value.

Call relations: Like skill_scope_user, this is a convenience wrapper over from_app_server_wire. It gives tests a clear way to request the repository skill scope while relying on the shared conversion path.

Call graph: calls 1 internal fn (from_app_server_wire).

fn from_app_server_wire(value: impl Serialize) -> T

Purpose: This helper converts an app-server protocol value into another compatible type by using JSON as the shared middle format. It is mainly a test guard: if the new protocol shape stops matching the legacy helper type, the test fails loudly.

Data flow: It receives any value that can be serialized, turns it into a JSON value, then tries to read that JSON back as the requested output type. On success it returns the converted value; on failure it panics with a message explaining that the wire value no longer maps correctly.

Call relations: The session and skill-scope helper functions all call this instead of duplicating conversion code. It sits at the center of those helpers, acting like an adapter between app-server protocol values and the older types that some TUI tests still expect.

Call graph: called by 3 (session_source_cli, skill_scope_repo, skill_scope_user); 1 external calls (to_value).

fn new(width: u16, height: u16) -> Self

Purpose: Creates a new in-memory terminal with a chosen width and height. Tests use it when they need a predictable fake screen to render into.

Data flow: The caller gives a width and height. The function turns on forced color output, creates a vt100 parser sized like that terminal, wraps it in a Crossterm backend, and returns a VT100Backend ready for drawing.

Call relations: Snapshot and rendering tests call this at the start of a UI check. After creation, the returned backend is handed to Ratatui code, which draws into the vt100 parser instead of the real terminal.

Call graph: called by 61 (thread_goal_ephemeral_error_message_renders_snapshot, render_footer_with_mode_indicator_and_context, chained_config_error_wraps_in_history_snapshot, approval_modal_exec_multiline_prefix_hides_execpolicy_option_snapshot, approval_modal_exec_snapshot, approval_modal_exec_without_reason_snapshot, approval_modal_patch_snapshot, app_server_guardian_review_denied_renders_denied_request_snapshot, app_server_guardian_review_timed_out_renders_timed_out_request_snapshot, guardian_approved_exec_renders_approved_request (+15 more)); 3 external calls (new, force_color_output, new).

fn vt100(&self) -> &vt100::Parser

Purpose: Gives read-only access to the underlying in-memory terminal parser. This is used when code needs to inspect what the fake terminal currently thinks is on screen.

Data flow: It reads the wrapped Crossterm backend and returns a reference to its writer, which is the vt100 parser. Nothing is changed.

Call relations: Other methods in this file call it when they need safe terminal facts, such as cursor position or screen size, without asking the real operating system terminal.

Call graph: called by 3 (get_cursor_position, size, window_size); 1 external calls (writer).

fn write(&mut self, buf: &[u8]) -> io::Result<usize>

Purpose: Lets raw bytes be written into the fake terminal. This is what makes the backend usable anywhere a normal writable output stream is expected.

Data flow: It receives a byte buffer, forwards those bytes into the vt100 parser through the wrapped backend, and returns how many bytes were accepted or an input/output error.

Call relations: This is part of Rust’s Write trait, meaning outside code can treat VT100Backend like an output destination. The bytes ultimately feed the in-memory terminal state.

Call graph: 1 external calls (writer_mut).

fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result

Purpose: Turns the fake terminal’s visible screen into text. Tests can use this to compare the rendered UI with an expected snapshot.

Data flow: It reads the vt100 screen contents and writes that plain text into the formatter supplied by Rust’s display system. It does not change the terminal.

Call relations: This supports formatting such as format!("{}", backend). It is the bridge from the simulated terminal screen to human-readable test output.

Call graph: 1 external calls (write!).

fn draw(&mut self, content: I) -> io::Result<()>

Purpose: Draws Ratatui cells into the fake terminal. A cell is one screen position with its character and style information.

Data flow: It receives an iterator of screen coordinates and cells, passes them to the wrapped Crossterm backend, and returns success or an input/output error. The in-memory terminal changes to reflect the drawn content.

Call relations: Ratatui calls this through the Backend trait during rendering. This method keeps the normal drawing path while ensuring the output lands in the vt100 parser.

Call graph: 1 external calls (draw).

fn hide_cursor(&mut self) -> io::Result<()>

Purpose: Records a request to hide the cursor in the fake terminal. This lets tests exercise the same cursor behavior as the real UI.

Data flow: It takes no extra input, forwards the hide-cursor command to the wrapped backend, and returns whether that worked. The fake terminal receives the corresponding terminal command.

Call relations: Ratatui or UI code calls this through the backend interface when the interface should not show a cursor. The work is delegated to Crossterm’s backend using the in-memory writer.

Call graph: 1 external calls (hide_cursor).

fn show_cursor(&mut self) -> io::Result<()>

Purpose: Records a request to show the cursor in the fake terminal. This mirrors what would happen on a real terminal at the end of a draw or interaction.

Data flow: It takes no extra input, forwards the show-cursor command, and returns success or an input/output error. The fake terminal state receives that command.

Call relations: Ratatui or UI code calls this through the backend interface when the cursor should become visible again. The command is passed on to Crossterm, but still writes only into memory.

Call graph: 1 external calls (show_cursor).

fn get_cursor_position(&mut self) -> io::Result<Position>

Purpose: Reports the cursor position from the fake terminal instead of querying the real terminal. This is important because real cursor queries can write to stdout and make tests unreliable.

Data flow: It reads the cursor position from the vt100 screen, converts it into Ratatui’s Position type, and returns it. It does not change anything.

Call relations: When Ratatui asks the backend where the cursor is, this method answers from VT100Backend::vt100. That keeps tests self-contained and avoids Crossterm calls that would talk to the actual terminal.

Call graph: calls 1 internal fn (vt100).

fn set_cursor_position(&mut self, position: P) -> io::Result<()>

Purpose: Moves the cursor inside the fake terminal. Rendering code uses this the same way it would move the cursor on a real screen.

Data flow: It receives a target position, forwards that position to the wrapped Crossterm backend, and returns success or an input/output error. The in-memory terminal receives cursor movement instructions.

Call relations: Ratatui calls this through the backend trait while drawing. This method delegates the command to Crossterm’s backend, which writes the terminal control sequence into the vt100 parser.

Call graph: 1 external calls (set_cursor_position).

fn clear(&mut self) -> io::Result<()>

Purpose: Clears the fake terminal screen. Tests need this because UI rendering often starts by wiping old content.

Data flow: It receives no extra input, forwards a clear command to the wrapped backend, and returns whether it succeeded. The vt100 screen is updated as if a real terminal had been cleared.

Call relations: Ratatui or UI setup code calls this through the backend interface. The method preserves the normal clear behavior while keeping all output inside the test backend.

Call graph: 1 external calls (clear).

fn clear_region(&mut self, clear_type: ClearType) -> io::Result<()>

Purpose: Clears a specific part of the fake terminal, such as from the cursor to the end of a line or screen. This supports more precise terminal updates during rendering.

Data flow: It receives a ClearType, which describes what area should be cleared, forwards that request to Crossterm’s backend, and returns success or an input/output error. The matching region in the in-memory terminal is affected.

Call relations: Ratatui calls this when it wants a partial clear rather than a full-screen clear. This method hands the command to the wrapped backend so the vt100 parser sees the same escape codes a real terminal would.

Call graph: 1 external calls (clear_region).

fn append_lines(&mut self, line_count: u16) -> io::Result<()>

Purpose: Adds blank lines below the current terminal content in the fake screen. This supports terminal behavior where output causes the screen to grow or scroll.

Data flow: It receives a number of lines, forwards that number to the wrapped backend, and returns success or an error. The in-memory terminal is updated according to the generated terminal commands.

Call relations: Ratatui can call this through the backend trait when it needs to append lines. The method delegates to Crossterm’s implementation while keeping the result testable in memory.

Call graph: 1 external calls (append_lines).

fn size(&self) -> io::Result<Size>

Purpose: Reports the fake terminal’s size. It deliberately avoids asking the real terminal, so tests get the width and height they requested when creating the backend.

Data flow: It reads rows and columns from the vt100 screen, converts them into Ratatui’s Size type using width as columns and height as rows, and returns that size.

Call relations: Ratatui asks for this through the backend interface when laying out the UI. This method gets the answer from VT100Backend::vt100, keeping layout decisions stable across different machines.

Call graph: calls 1 internal fn (vt100); 1 external calls (new).

fn window_size(&mut self) -> io::Result<WindowSize>

Purpose: Reports the fake terminal’s character size plus a placeholder pixel size. The character size matters for tests; the pixel size is arbitrary because these tests do not depend on it.

Data flow: It reads the fake screen’s rows and columns, places them into a WindowSize, fills in a fixed 640 by 480 pixel value, and returns the result.

Call relations: Code that asks for full window dimensions calls this through the backend trait. It uses VT100Backend::vt100 for the meaningful terminal size and avoids a real Crossterm window-size query.

Call graph: calls 1 internal fn (vt100).

fn flush(&mut self) -> io::Result<()>

Purpose: Flushes pending output into the in-memory terminal writer. Flushing means asking the output stream to finish sending anything it has buffered.

Data flow: It takes no extra input, calls flush on the vt100 writer inside the wrapped backend, and returns success or an input/output error. It does not produce a new value beyond that status.

Call relations: Ratatui or other output code calls this through the backend interface after writing commands. This makes the fake backend behave like a normal terminal output stream.

Call graph: 1 external calls (writer_mut).

fn scroll_region_up(&mut self, region: std::ops::Range<u16>, scroll_by: u16) -> io::Result<()>

Purpose: Scrolls a selected vertical region of the fake terminal upward. This supports terminal UIs that move part of the screen without redrawing everything.

Data flow: It receives a range of rows and a number of rows to scroll by, forwards both to the wrapped backend, and returns success or an error. The vt100 screen changes as if that region had scrolled up.

Call relations: Ratatui calls this through the backend trait when it uses terminal scrolling commands. The method passes the request to Crossterm so the vt100 parser can interpret the same command sequence used in real output.

Call graph: 1 external calls (scroll_region_up).

fn scroll_region_down(
        &mut self,
        region: std::ops::Range<u16>,
        scroll_by: u16,
    ) -> io::Result<()>

Purpose: Scrolls a selected vertical region of the fake terminal downward. This is the downward counterpart to scrolling a region up.

Data flow: It receives a row range and a scroll amount, forwards them to the wrapped backend, and returns success or an input/output error. The fake terminal screen is updated to reflect the downward scroll.

Call relations: Ratatui calls this through the backend trait when drawing code needs downward scrolling. This method delegates the actual terminal command generation to Crossterm while keeping the effect inside the vt100 test screen.

Call graph: 1 external calls (scroll_region_down).

fn chatwidget_snapshot_dir() -> PathBuf

Purpose: Finds the directory that contains the saved snapshot files for chat widget tests. Test code uses this so snapshot comparisons always look in the same known place, even when tests are run from different working directories.

Data flow: It starts with the known path of one snapshot resource inside the project. It asks the build/resource helper to locate that file, takes the file’s parent folder, and returns that folder as a path. If the snapshot file or its parent folder cannot be found, the test fails immediately because snapshot comparisons would not be trustworthy.

Call relations: The snapshot assertion helper in this file relies on this function when setting up the snapshot test settings. It hands the resolved folder path to the snapshot library so rendered chat widget output is compared against the correct saved files.

Call graph: 1 external calls (find_resource!).

fn next_goal_draft(
    rx: &mut tokio::sync::mpsc::UnboundedReceiver<AppEvent>,
    expected_thread_id: ThreadId,
) -> crate::goal_files::GoalDraft

Purpose: Waits through pending test events until it finds the next event that updates a thread’s goal draft. It also checks that the update belongs to the thread the test expected.

Data flow: It receives a test event receiver and the thread identifier that should own the goal draft. It repeatedly pulls the next available event from the receiver. When it finds a goal-draft update event, it compares the event’s thread identifier with the expected one and then returns the draft from that event. Any missing event or wrong thread causes the test to fail.

Call relations: Goal-related chat widget tests use this as a focused checker after user actions or widget logic send events. It reads from the app event channel, filters for the goal-draft update, verifies the thread match with an equality assertion, and gives the draft back to the test so the test can inspect the result.

Call graph: 2 external calls (try_recv, assert_eq!).

async fn test_config() -> Config

Purpose: Builds a clean Config for tests. It avoids using the real machine’s Codex settings by creating a temporary home folder and resetting test-sensitive fields.

Data flow: It starts with a new temporary directory, loads default configuration using that directory, then rewrites paths such as Codex home, SQLite home, log directory, and current working directory to known test values. It returns a Config that is safe and predictable for tests.

Call relations: The main ChatWidget builder, make_chatwidget_manual_with_auth, calls this first so every fake widget starts from the same isolated environment.

Call graph: called by 1 (make_chatwidget_manual_with_auth); 5 external calls (from, new, load_default_with_cli_overrides_for_codex_home, default, new).

fn test_project_path() -> PathBuf

Purpose: Returns the standard fake project path used by tests. This gives tests one shared idea of where the project lives.

Data flow: It takes no input, converts the test path string for the current platform, and returns it as a PathBuf.

Call relations: Tests can call this directly when they need to compare or build paths that match the helper-created ChatWidget configuration.

Call graph: 1 external calls (from).

fn truncated_path_variants(path: &str) -> Vec<String>

Purpose: Creates all shortened prefixes of a path string. This is useful when snapshot text contains a path that was shortened with an ellipsis.

Data flow: It receives a path, splits it into characters, then returns every prefix except the full path. The output is a list from shortest to longest prefix.

Call relations: normalize_snapshot_paths uses it when converting platform-specific shortened paths back to the Unix-style paths expected in snapshots.

Call graph: called by 1 (normalize_snapshot_paths).

fn normalize_snapshot_paths(text: impl Into<String>) -> String

Purpose: Makes snapshot text stable across operating systems by replacing platform-specific test paths with Unix-style paths. This prevents Windows path separators or drive formatting from breaking snapshots.

Data flow: It receives text, replaces known platform paths such as the fake project and hooks file with canonical Unix-looking versions, and also fixes shortened path-with-ellipsis forms. It returns the normalized text.

Call relations: Snapshot-oriented helpers and tests use this when rendered output may include file paths. It relies on truncated_path_variants for shortened path cases.

Call graph: calls 1 internal fn (truncated_path_variants); 3 external calls (into, replace, format!).

fn normalized_backend_snapshot(value: &T) -> String

Purpose: Normalizes backend-rendered snapshot text while preserving quoted-line padding. This keeps visual alignment intact after path replacement.

Data flow: It formats the input value as text. If the platform path already matches the expected Unix path, it returns that text. Otherwise, it normalizes each line and keeps quoted content padded to its original width.

Call relations: Tests use this when comparing backend display output that may contain paths and fixed-width quoted text.

Call graph: 1 external calls (format!).

fn invalid_value(
    candidate: impl Into<String>,
    allowed: impl Into<String>,
) -> ConstraintError

Purpose: Builds a standard constraint error for tests that need an invalid setting value. It saves each test from spelling out the same error fields.

Data flow: It receives the rejected value and a description of allowed values, puts them into a ConstraintError::InvalidValue with placeholder metadata, and returns the error.

Call relations: Tests can use this as ready-made expected data when checking validation behavior.

Call graph: 1 external calls (into).

fn snapshot(percent: f64) -> RateLimitSnapshot

Purpose: Creates a simple rate-limit snapshot with one primary usage percentage. Tests use it to exercise UI around usage limits without building the full structure each time.

Data flow: It receives a percent value, rounds it to an integer, places it into a one-hour rate-limit window, and returns a RateLimitSnapshot with other fields empty.

Call relations: Tests can pass its result into ChatWidget code that displays or reacts to rate-limit state.

fn test_session_telemetry(config: &Config, model: &str) -> SessionTelemetry

Purpose: Creates fake session telemetry for a test chat session. Telemetry here means metadata about the session, such as model and source, not real reporting.

Data flow: It reads the test Config and model name, constructs offline model information, then creates a SessionTelemetry object with test-only identifiers and no account details.

Call relations: make_chatwidget_manual_with_auth calls this while assembling the ChatWidget initialization data.

Call graph: calls 3 internal fn (new, new, session_source_cli); called by 1 (make_chatwidget_manual_with_auth); 1 external calls (to_models_manager_config).

fn test_model_catalog(_config: &Config) -> Arc<ModelCatalog>

Purpose: Builds a shared catalog of test model presets. This gives the widget realistic model choices without contacting a service.

Data flow: It ignores the config, clones predefined test model presets, wraps them in a ModelCatalog, and returns it in an Arc, which is a shared reference-counted pointer.

Call relations: Widget builders and authentication helpers use this to populate or reset the ChatWidget’s model list.

Call graph: calls 1 internal fn (new); called by 2 (make_chatwidget_manual_with_auth, set_chatgpt_auth); 1 external calls (new).

async fn make_chatwidget_manual(
    model_override: Option<&str>,
) -> (
    ChatWidget,
    tokio::sync::mpsc::UnboundedReceiver<AppEvent>,
    tokio::sync::mpsc::UnboundedReceiver<Op>,
)

Purpose: Creates a basic ChatWidget test instance without authenticated-account flags. It is the simplest entry point for tests that need to drive the widget directly.

Data flow: It receives an optional model override and forwards it with both authentication flags set to false. It returns the widget plus receivers for app events and operations.

Call relations: Many tests and helper builders call this when they do not need special authentication behavior. It delegates all real setup to make_chatwidget_manual_with_auth.

Call graph: calls 1 internal fn (make_chatwidget_manual_with_auth); called by 3 (assert_hook_events_snapshot, assert_shift_left_edits_most_recent_queued_message_for_terminal, make_chatwidget_manual_with_sender).

async fn make_chatwidget_manual_with_auth(
    model_override: Option<&str>,
    has_chatgpt_account: bool,
    has_codex_backend_auth: bool,
) -> (
    ChatWidget,
    tokio::sync::mpsc::UnboundedRec

Purpose: Builds a fully usable ChatWidget for tests, with optional model and authentication settings. It also exposes the channels where the widget sends events and operations.

Data flow: It creates event and operation channels, loads a clean test config, resolves the model, builds telemetry and model catalog data, constructs ChatWidgetInit, creates the widget, resets some visual state, sets placeholder text, and returns the widget with channel receivers.

Call relations: make_chatwidget_manual calls this for normal setup. Other helpers depend on the widget it produces to simulate server events and inspect outgoing operations.

Call graph: calls 6 internal fn (new, new, test_config, test_model_catalog, test_session_telemetry, test_dummy); called by 1 (make_chatwidget_manual); 4 external calls (new, new, new_with_op_target, Direct).

fn next_submit_op(op_rx: &mut tokio::sync::mpsc::UnboundedReceiver<Op>) -> Op

Purpose: Pulls the next user-submission operation from the operation channel. It skips unrelated operations so tests can focus on whether a submit happened.

Data flow: It repeatedly tries to receive from the channel. If it sees a UserTurn operation, it returns it; if it sees another operation, it ignores it; if the queue is empty or closed, it panics because the test expected a submission.

Call relations: Tests use this after triggering input in the widget to verify the widget sent a user turn.

Call graph: 2 external calls (try_recv, panic!).

fn next_interrupt_op(op_rx: &mut tokio::sync::mpsc::UnboundedReceiver<Op>)

Purpose: Checks that the widget emitted an interrupt operation. This is used when a test expects the user action to stop a running task.

Data flow: It reads operations until it finds Interrupt, ignores unrelated operations, and panics if the channel is empty or closed first. It returns nothing because finding the operation is the assertion.

Call relations: Tests call it after simulating an interrupt action such as a cancel key.

Call graph: 2 external calls (try_recv, panic!).

fn assert_no_submit_op(op_rx: &mut tokio::sync::mpsc::UnboundedReceiver<Op>)

Purpose: Verifies that no user-submission operation is waiting in the operation channel. This protects tests from accidental sends.

Data flow: It drains currently available operations. If any operation is UserTurn, it fails the test; otherwise it leaves with no result.

Call relations: Tests use it after actions that should edit UI state or queue text but should not submit a message.

Call graph: 2 external calls (try_recv, assert!).

fn set_chatgpt_auth(chat: &mut ChatWidget)

Purpose: Marks a test ChatWidget as having both ChatGPT and Codex backend authentication. This lets tests exercise account-gated behavior.

Data flow: It mutates the widget by setting both auth flags to true and replacing the model catalog with the standard test catalog.

Call relations: Tests call this after creating a widget when they need the authenticated version of model or account behavior.

Call graph: calls 1 internal fn (test_model_catalog).

fn test_model_info(slug: &str, priority: i32, supports_fast_mode: bool) -> ModelInfo

Purpose: Creates detailed fake information for one model. It can optionally mark the model as supporting fast mode.

Data flow: It receives a model slug, priority, and fast-mode flag, builds JSON-like model metadata, then deserializes it into a ModelInfo. The returned model info is realistic enough for catalog tests.

Call relations: set_fast_mode_test_catalog uses it to build a catalog with both fast-mode and non-fast-mode models.

Call graph: 3 external calls (new, json!, from_value).

fn set_fast_mode_test_catalog(chat: &mut ChatWidget)

Purpose: Replaces a ChatWidget’s model catalog with two test models, one that supports fast mode and one that does not. This helps tests check fast-mode UI decisions.

Data flow: It builds two ModelInfo records, converts them into model presets, wraps them in a ModelCatalog, and stores that catalog on the widget.

Call relations: Tests call this when they need controlled fast-mode availability rather than the default test model list.

Call graph: calls 1 internal fn (new); 2 external calls (new, vec!).

async fn make_chatwidget_manual_with_sender() -> (
    ChatWidget,
    AppEventSender,
    tokio::sync::mpsc::UnboundedReceiver<AppEvent>,
    tokio::sync::mpsc::UnboundedReceiver<Op>,
)

Purpose: Creates a test ChatWidget and also returns its AppEventSender. This lets tests both drive and observe app events.

Data flow: It builds a normal manual widget, clones the widget’s event sender, and returns the widget, sender, app-event receiver, and operation receiver.

Call relations: It builds on make_chatwidget_manual and is useful for tests that need to inject events through the same sender the widget uses.

Call graph: calls 1 internal fn (make_chatwidget_manual).

fn drain_insert_history(
    rx: &mut tokio::sync::mpsc::UnboundedReceiver<AppEvent>,
) -> Vec<Vec<ratatui::text::Line<'static>>>

Purpose: Collects all pending history-cell insert events from the app event channel. It converts them into display lines for easy snapshot checking.

Data flow: It drains currently available app events, keeps only InsertHistoryCell events, renders each cell at width 80, inserts a blank separator where needed, and returns a list of rendered line groups.

Call relations: assert_hook_events_snapshot uses it to check that hook output moved from the live area into history at the right time.

Call graph: called by 1 (assert_hook_events_snapshot); 2 external calls (try_recv, new).

fn lines_to_single_string(lines: &[ratatui::text::Line<'static>]) -> String

Purpose: Turns rendered terminal lines into one plain string. This makes snapshot assertions easy to read.

Data flow: It receives a slice of ratatui Lines, concatenates the text from each span in each line, adds newline characters, and returns the combined string.

Call relations: active_blob and active_hook_blob use it after asking cells to render themselves.

Call graph: called by 2 (active_blob, active_hook_blob); 1 external calls (new).

fn status_line_text(chat: &ChatWidget) -> Option<String>

Purpose: Reads the current status-line text from a ChatWidget. It is a small wrapper used by tests.

Data flow: It receives a widget reference, calls the widget’s status-line accessor, and returns the optional text.

Call relations: Tests use this helper instead of reaching deeper into widget internals.

Call graph: calls 1 internal fn (status_line_text).

fn make_token_info(total_tokens: i64, context_window: i64) -> TokenUsageInfo

Purpose: Creates token usage information for tests. Tokens are the small pieces of text counted against a model’s context window.

Data flow: It receives total token count and context-window size, fills both total and last-turn usage with that count, and returns a TokenUsageInfo object.

Call relations: Tests can pass its result to handle_token_count to simulate server updates about context usage.

fn thread_id(chat: &ChatWidget) -> String

Purpose: Gets the widget’s thread id as a string, or an empty string if none exists. A thread id identifies the conversation.

Data flow: It reads chat.thread_id, converts it to text when present, and otherwise returns an empty string.

Call relations: Most server-notification helpers call this so their fake events look like they belong to the current chat thread.

Call graph: called by 21 (handle_agent_message_delta, handle_agent_reasoning_delta, handle_agent_reasoning_final, handle_entered_review_mode, handle_error, handle_exec_begin, handle_exec_end, handle_exited_review_mode, handle_hook_completed, handle_hook_started (+11 more)).

fn token_usage_breakdown(usage: TokenUsage) -> codex_app_server_protocol::TokenUsageBreakdown

Purpose: Converts the UI-side token usage structure into the protocol-side token usage structure. This lets tests send usage updates through the same path as the server.

Data flow: It receives TokenUsage, copies each token count field into a codex_app_server_protocol::TokenUsageBreakdown, and returns it.

Call relations: handle_token_count uses it when building a fake ThreadTokenUsageUpdated notification.

Call graph: called by 1 (handle_token_count).

fn handle_token_count(chat: &mut ChatWidget, info: Option<TokenUsageInfo>)

Purpose: Simulates the server telling the widget that token usage changed. It can also clear token information.

Data flow: If given usage info, it builds a ThreadTokenUsageUpdated notification with thread and turn ids, converts token details, and sends it into the widget. If given None, it directly clears the widget’s token info.

Call relations: Tests use this to drive the same update path the widget uses during real conversations.

Call graph: calls 3 internal fn (set_token_info, thread_id, token_usage_breakdown); 2 external calls (ThreadTokenUsageUpdated, handle_server_notification).

fn handle_error(
    chat: &mut ChatWidget,
    message: impl Into<String>,
    codex_error_info: Option<CodexErrorInfo>,
)

Purpose: Simulates a non-retrying error from the server. This tests how the widget displays or reacts to failures.

Data flow: It receives a message and optional Codex error details, wraps them in an Error notification with the current thread and turn, and sends it to the widget.

Call relations: Tests call it when they need the widget to process a final error for the current turn.

Call graph: calls 1 internal fn (thread_id); 3 external calls (into, Error, handle_server_notification).

fn handle_stream_error(
    chat: &mut ChatWidget,
    message: impl Into<String>,
    additional_details: Option<String>,
)

Purpose: Simulates a retrying stream error without replay metadata. A stream error is a failure while output is still arriving.

Data flow: It accepts a message and optional details, then forwards them to handle_stream_error_with_replay with no replay kind. It returns nothing after the widget processes the event.

Call relations: It is the convenient form for tests that do not care about replay behavior.

Call graph: calls 1 internal fn (handle_stream_error_with_replay).

fn handle_stream_error_with_replay(
    chat: &mut ChatWidget,
    message: impl Into<String>,
    additional_details: Option<String>,
    replay_kind: Option<ReplayKind>,
)

Purpose: Simulates a retrying stream error and optionally marks it as replayed history. This lets tests cover both live and replay paths.

Data flow: It builds an Error notification with will_retry set to true, fills in thread and turn ids, includes optional details, and sends it to the widget with the supplied replay kind.

Call relations: handle_stream_error delegates to it. Tests call it directly when they need to specify replay behavior.

Call graph: calls 1 internal fn (thread_id); called by 1 (handle_stream_error); 3 external calls (into, Error, handle_server_notification).

fn handle_warning(chat: &mut ChatWidget, message: impl Into<String>)

Purpose: Simulates a warning from the server. Warnings are messages the user should see but that do not necessarily stop the turn.

Data flow: It receives warning text, builds a Warning notification with the current thread id, and sends it into the widget.

Call relations: Tests use it to check warning rendering and history behavior.

Call graph: calls 1 internal fn (thread_id); 3 external calls (into, Warning, handle_server_notification).

fn handle_model_verification(
    chat: &mut ChatWidget,
    verifications: Vec<AppServerModelVerification>,
)

Purpose: Simulates the server reporting model-verification results. This supports tests around model availability or compatibility messages.

Data flow: It receives verification records, attaches them to the current thread and turn, builds a ModelVerification notification, and sends it to the widget.

Call relations: Tests call it when they need the ChatWidget to react as if the backend checked the chosen model.

Call graph: calls 1 internal fn (thread_id); 2 external calls (ModelVerification, handle_server_notification).

fn handle_agent_message_delta(chat: &mut ChatWidget, delta: impl Into<String>)

Purpose: Simulates one streamed chunk of assistant text. A delta is a small piece of a message that arrives before the full answer is complete.

Data flow: It receives text, wraps it with fixed item id msg-1 plus current thread and turn ids, and sends an AgentMessageDelta notification to the widget.

Call relations: Tests use it to build up live assistant output through the normal server-notification path.

Call graph: calls 1 internal fn (thread_id); 3 external calls (into, AgentMessageDelta, handle_server_notification).

fn handle_agent_reasoning_delta(chat: &mut ChatWidget, delta: impl Into<String>)

Purpose: Simulates one streamed chunk of the assistant’s reasoning summary. This is separate from the final answer text.

Data flow: It receives text, builds a ReasoningSummaryTextDelta notification for item reasoning-1, and sends it to the widget.

Call relations: Tests use it to check how live reasoning summary text appears or changes.

Call graph: calls 1 internal fn (thread_id); 3 external calls (into, ReasoningSummaryTextDelta, handle_server_notification).

fn handle_agent_reasoning_final(chat: &mut ChatWidget)

Purpose: Simulates completion of a reasoning item. This tells the widget that the reasoning stream is done.

Data flow: It builds an ItemCompleted notification for a Reasoning item with id reasoning-1 and empty final content, then sends it to the widget.

Call relations: Tests call it after reasoning deltas when they need to close out the reasoning cell.

Call graph: calls 1 internal fn (thread_id); 3 external calls (ItemCompleted, new, handle_server_notification).

fn handle_entered_review_mode(chat: &mut ChatWidget, review: impl Into<String>)

Purpose: Simulates the server starting review mode. Review mode is represented as a thread item that begins at a point in the turn.

Data flow: It receives review text, creates an EnteredReviewMode item inside an ItemStarted notification, and sends it to the widget.

Call relations: Tests use it to verify the widget’s live display when review mode begins.

Call graph: calls 1 internal fn (thread_id); 3 external calls (into, ItemStarted, handle_server_notification).

fn replay_entered_review_mode(chat: &mut ChatWidget, review: impl Into<String>)

Purpose: Replays an already-existing review-mode entry into the widget. Replaying means rebuilding UI from saved thread history rather than receiving a live event.

Data flow: It creates an EnteredReviewMode thread item with fixed id and turn id, then asks the widget to replay it as a thread snapshot.

Call relations: Tests use this when they need to compare live handling with restored-history handling.

Call graph: 2 external calls (into, replay_thread_item).

fn handle_exited_review_mode(chat: &mut ChatWidget)

Purpose: Simulates the server completing review mode. It marks the review-mode item as ended.

Data flow: It builds an ItemCompleted notification with an ExitedReviewMode item and sends it to the widget.

Call relations: Tests call it after entering review mode to check transition and final rendering behavior.

Call graph: calls 1 internal fn (thread_id); 3 external calls (ItemCompleted, new, handle_server_notification).

fn handle_exec_approval_request(
    chat: &mut ChatWidget,
    id: impl Into<String>,
    event: ExecApprovalRequestEvent,
)

Purpose: Feeds a command-execution approval request into the widget. This simulates the backend asking whether it may run a command.

Data flow: It receives an id and approval event, converts the id to a string, and calls the widget’s approval-request method. The widget state is updated to show or track the request.

Call relations: Tests use it to drive the same path as a real command permission prompt.

Call graph: 2 external calls (into, on_exec_approval_request).

fn handle_apply_patch_approval_request(
    chat: &mut ChatWidget,
    id: impl Into<String>,
    event: ApplyPatchApprovalRequestEvent,
)

Purpose: Feeds a patch-application approval request into the widget. This simulates asking the user before changing files.

Data flow: It receives an id and patch approval event, converts the id to text, and calls the widget’s patch approval-request method.

Call relations: Tests use it to check UI behavior around approving or denying file changes.

Call graph: 2 external calls (into, on_apply_patch_approval_request).

fn file_update_changes_from_tui(changes: HashMap<PathBuf, FileChange>) -> Vec<FileUpdateChange>

Purpose: Converts test-side file-change descriptions into protocol file-update changes. This bridges the UI test type and the server item type.

Data flow: It receives a map from file paths to add, delete, or update changes. For each entry, it chooses the matching protocol change kind, converts the path to display text, and returns a list of FileUpdateChange records.

Call relations: handle_patch_apply_begin and handle_patch_apply_end use it before sending patch events to the widget.

Call graph: called by 2 (handle_patch_apply_begin, handle_patch_apply_end).

fn handle_patch_apply_begin(
    chat: &mut ChatWidget,
    call_id: impl Into<String>,
    turn_id: impl Into<String>,
    changes: HashMap<PathBuf, FileChange>,
)

Purpose: Simulates the start of applying a patch to files. This lets tests check how in-progress file changes are shown.

Data flow: It receives call id, turn id, and file changes, converts the changes to protocol form, wraps them in an in-progress FileChange item, and sends an ItemStarted notification.

Call relations: It uses file_update_changes_from_tui to prepare the payload before passing it through the widget’s normal server-notification handler.

Call graph: calls 2 internal fn (file_update_changes_from_tui, thread_id); 3 external calls (into, ItemStarted, handle_server_notification).

fn handle_patch_apply_end(
    chat: &mut ChatWidget,
    call_id: impl Into<String>,
    turn_id: impl Into<String>,
    changes: HashMap<PathBuf, FileChange>,
    status: AppServerPatchApplyStatus,

Purpose: Simulates the completion of applying a patch. It can represent success, failure, or another final patch status.

Data flow: It receives ids, file changes, and status, converts the changes, builds a completed FileChange item, and sends an ItemCompleted notification to the widget.

Call relations: Tests pair it with handle_patch_apply_begin when checking patch lifecycle display.

Call graph: calls 2 internal fn (file_update_changes_from_tui, thread_id); 3 external calls (into, ItemCompleted, handle_server_notification).

fn handle_view_image_tool_call(
    chat: &mut ChatWidget,
    call_id: impl Into<String>,
    path: AbsolutePathBuf,
)

Purpose: Simulates completion of a tool call that views an image. This tests image-view entries in the transcript.

Data flow: It receives a call id and absolute image path, wraps them in an ImageView item for turn-1, and sends an ItemCompleted notification.

Call relations: Tests use it when verifying how image-view tool results are rendered.

Call graph: calls 1 internal fn (thread_id); 3 external calls (into, ItemCompleted, handle_server_notification).

fn handle_image_generation_end(
    chat: &mut ChatWidget,
    call_id: impl Into<String>,
    status: impl Into<String>,
    revised_prompt: Option<String>,
    saved_path: Option<AbsolutePathBuf>,
)

Purpose: Simulates completion of an image-generation tool call. It includes status, optional revised prompt, and optional saved file path.

Data flow: It receives image-generation details, builds an ImageGeneration item with an empty result string, and sends it as a completed item to the widget.

Call relations: Tests call it to verify image-generation result display and saved-path behavior.

Call graph: calls 1 internal fn (thread_id); 4 external calls (into, ItemCompleted, new, handle_server_notification).

fn replay_user_message_inputs(
    chat: &mut ChatWidget,
    item_id: &str,
    content: Vec<AppServerUserInput>,
    replay_kind: ReplayKind,
)

Purpose: Replays a saved user message with arbitrary input parts. Inputs may include text or other supported user content.

Data flow: It receives an item id, content list, and replay kind, creates a UserMessage thread item, and asks the widget to replay it for turn-1.

Call relations: replay_user_message_text uses it for the common text-only case. Tests use it for restored-history scenarios.

Call graph: called by 1 (replay_user_message_text); 1 external calls (replay_thread_item).

fn replay_user_message_text(
    chat: &mut ChatWidget,
    item_id: &str,
    text: impl Into<String>,
    replay_kind: ReplayKind,
)

Purpose: Replays a saved text-only user message. This is the simple wrapper for common history tests.

Data flow: It receives an item id, text, and replay kind, wraps the text in a single text input, and forwards everything to replay_user_message_inputs.

Call relations: It reduces boilerplate for tests that do not need mixed input types.

Call graph: calls 1 internal fn (replay_user_message_inputs); 1 external calls (vec!).

fn replay_agent_message(
    chat: &mut ChatWidget,
    item_id: &str,
    text: impl Into<String>,
    replay_kind: ReplayKind,
)

Purpose: Replays a saved assistant message. It marks the message as a final answer.

Data flow: It receives an item id, text, and replay kind, creates an AgentMessage thread item with FinalAnswer phase, and asks the widget to replay it for turn-1.

Call relations: Tests use it to rebuild transcript state from history without simulating live streaming.

Call graph: 2 external calls (into, replay_thread_item).

fn replay_turn_started(chat: &mut ChatWidget, replay_kind: ReplayKind)

Purpose: Replays a turn-started notification. A turn is one request-response cycle in the conversation.

Data flow: It builds an in-progress AppServerTurn for turn-1, wraps it in a TurnStarted notification, and sends it to the widget with replay metadata.

Call relations: It uses app_server_turn to create the standard turn object used by both live and replay helpers.

Call graph: calls 2 internal fn (app_server_turn, thread_id); 2 external calls (TurnStarted, handle_server_notification).

fn replay_agent_message_delta(
    chat: &mut ChatWidget,
    delta: impl Into<String>,
    replay_kind: ReplayKind,
)

Purpose: Replays a streamed assistant message chunk. This is useful for tests that restore an in-progress or previously streamed message.

Data flow: It receives text and replay kind, creates an AgentMessageDelta notification for msg-1 on turn-1, and sends it to the widget with replay metadata.

Call relations: Tests use it when they need replay behavior but still want to exercise the delta-handling path.

Call graph: calls 1 internal fn (thread_id); 3 external calls (into, AgentMessageDelta, handle_server_notification).

fn begin_exec_with_source(
    chat: &mut ChatWidget,
    call_id: &str,
    raw_cmd: &str,
    source: ExecCommandSource,
) -> AppServerThreadItem

Purpose: Starts a fake command execution with a chosen source. The source says why the command is running, such as from the agent or startup flow.

Data flow: It receives a widget, call id, raw shell command, and source. It builds a bash command, parses it into command actions, creates an in-progress CommandExecution item, sends a begin event, and returns the item for later completion.

Call relations: begin_exec calls it with the normal agent source. It hands the item to handle_exec_begin so the widget sees the same event shape as a real command start.

Call graph: calls 3 internal fn (parse_command, shlex_join, handle_exec_begin); called by 1 (begin_exec); 1 external calls (vec!).

fn begin_unified_exec_startup(
    chat: &mut ChatWidget,
    call_id: &str,
    process_id: &str,
    raw_cmd: &str,
) -> AppServerThreadItem

Purpose: Starts a fake command execution for unified-exec startup behavior. It includes a process id and uses a startup-specific source.

Data flow: It receives ids and raw command text, builds the shell command item with in-progress status and no parsed actions, sends it as a begin event, and returns the item.

Call relations: It delegates delivery to handle_exec_begin and is used by tests for this special startup command path.

Call graph: calls 2 internal fn (shlex_join, handle_exec_begin); 2 external calls (new, vec!).

fn handle_exec_begin(chat: &mut ChatWidget, item: AppServerThreadItem)

Purpose: Sends a command or other started thread item into the widget. It represents the server saying an item has begun.

Data flow: It receives a thread item, wraps it in an ItemStarted notification with current thread and turn ids, and passes it to the widget.

Call relations: begin_exec_with_source and begin_unified_exec_startup use it after constructing command-execution items.

Call graph: calls 1 internal fn (thread_id); called by 2 (begin_exec_with_source, begin_unified_exec_startup); 2 external calls (ItemStarted, handle_server_notification).

fn terminal_interaction(
    chat: &mut ChatWidget,
    call_id: &str,
    process_id: &str,
    stdin: &str,
)

Purpose: Simulates user input being sent to a running terminal process. This tests transcript and state around interactive commands.

Data flow: It receives call id, process id, and stdin text, builds a TerminalInteraction notification with current thread and turn ids, and sends it to the widget.

Call relations: Tests use it after starting a command when they need to show or process input sent to that command.

Call graph: calls 1 internal fn (thread_id); 2 external calls (TerminalInteraction, handle_server_notification).

fn complete_assistant_message(
    chat: &mut ChatWidget,
    item_id: &str,
    text: &str,
    phase: Option<MessagePhase>,
)

Purpose: Simulates a completed assistant message. It can optionally specify the message phase.

Data flow: It receives item id, message text, and phase, creates an AgentMessage item, wraps it in an ItemCompleted notification for turn-1, and sends it to the widget.

Call relations: Tests use it when they want a full assistant message without streaming deltas first.

Call graph: 2 external calls (ItemCompleted, handle_server_notification).

fn pending_steer(text: &str) -> PendingSteer

Purpose: Creates a pending steer from text. A steer is a queued user instruction meant to guide an ongoing conversation.

Data flow: It receives text, builds a UserMessage, a matching history record type, and a compare key with zero images, then returns the PendingSteer.

Call relations: Tests use it as compact setup for input-queue or steering behavior.

Call graph: calls 1 internal fn (from).

fn complete_user_message(chat: &mut ChatWidget, item_id: &str, text: &str)

Purpose: Simulates completion of a text-only user message. This is the common wrapper around the more general input helper.

Data flow: It receives a widget, item id, and text, wraps the text as one UserInput::Text, and forwards it to complete_user_message_for_inputs.

Call relations: It delegates to complete_user_message_for_inputs, which sends the actual notification.

Call graph: calls 1 internal fn (complete_user_message_for_inputs); 1 external calls (vec!).

fn complete_user_message_for_inputs(
    chat: &mut ChatWidget,
    item_id: &str,
    content: Vec<UserInput>,
)

Purpose: Simulates completion of a user message with arbitrary input parts. This tests how the widget records submitted user content.

Data flow: It receives content inputs, creates a UserMessage item with no client id, wraps it in an ItemCompleted notification for turn-1, and sends it to the widget.

Call relations: complete_user_message uses it for the text-only case. Tests call it directly for richer user input.

Call graph: called by 1 (complete_user_message); 2 external calls (ItemCompleted, handle_server_notification).

fn app_server_turn(
    turn_id: &str,
    status: AppServerTurnStatus,
    duration_ms: Option<i64>,
    error: Option<AppServerTurnError>,
) -> AppServerTurn

Purpose: Builds a standard AppServerTurn object for tests. It fills only the fields tests usually need.

Data flow: It receives turn id, status, optional duration, and optional error, then returns a turn with full item view, no items, and empty timestamps.

Call relations: Turn-start, turn-complete, interrupted, and replay helpers all use this to keep turn objects consistent.

Call graph: called by 4 (handle_turn_completed, handle_turn_interrupted, handle_turn_started, replay_turn_started); 1 external calls (new).

fn handle_turn_started(chat: &mut ChatWidget, turn_id: &str)

Purpose: Simulates the server starting a turn. This tells the widget a new request-response cycle is in progress.

Data flow: It receives a turn id, builds an in-progress turn, wraps it in a TurnStarted notification, and sends it to the widget.

Call relations: It uses app_server_turn for the payload and feeds the result through the normal server-notification path.

Call graph: calls 1 internal fn (app_server_turn); 2 external calls (TurnStarted, handle_server_notification).

fn handle_turn_completed(
    chat: &mut ChatWidget,
    turn_id: &str,
    duration_ms: Option<i64>,
)

Purpose: Simulates a turn finishing successfully. It can include how long the turn took.

Data flow: It receives a turn id and optional duration, builds a completed turn with no error, wraps it in a TurnCompleted notification, and sends it to the widget.

Call relations: Tests call it at the end of simulated conversations to verify final state and display.

Call graph: calls 1 internal fn (app_server_turn); 2 external calls (TurnCompleted, handle_server_notification).

fn handle_turn_interrupted(chat: &mut ChatWidget, turn_id: &str)

Purpose: Simulates a turn ending because it was interrupted. This is different from normal completion.

Data flow: It receives a turn id, builds an interrupted turn, wraps it in a TurnCompleted notification, and sends it to the widget.

Call relations: handle_budget_limited_turn calls it after marking the turn as budget-limited. Tests also call it directly for cancel-like flows.

Call graph: calls 1 internal fn (app_server_turn); called by 1 (handle_budget_limited_turn); 2 external calls (TurnCompleted, handle_server_notification).

fn handle_budget_limited_turn(chat: &mut ChatWidget, turn_id: &str)

Purpose: Marks a turn as stopped because of a budget limit, then sends the interrupted-turn event. This tests the special UI for budget-limited interruptions.

Data flow: It receives a widget and turn id, records the budget-limited state in the widget’s turn lifecycle, then calls handle_turn_interrupted.

Call relations: It builds on handle_turn_interrupted but adds the extra state needed for budget-limit behavior.

Call graph: calls 1 internal fn (handle_turn_interrupted).

fn begin_exec(
    chat: &mut ChatWidget,
    call_id: &str,
    raw_cmd: &str,
) -> AppServerThreadItem

Purpose: Starts a normal fake agent command execution. It is the simplest command-start helper.

Data flow: It receives a widget, call id, and raw command, then forwards them to begin_exec_with_source with the Agent source. It returns the started command item.

Call relations: Tests use it before calling end_exec when they want a full command lifecycle.

Call graph: calls 1 internal fn (begin_exec_with_source).

fn end_exec(
    chat: &mut ChatWidget,
    begin_item: AppServerThreadItem,
    stdout: &str,
    stderr: &str,
    exit_code: i32,
)

Purpose: Completes a fake command execution that was previously started. It chooses success or failure based on the exit code.

Data flow: It receives the original command item plus stdout, stderr, and exit code. It combines output, extracts command fields from the started item, builds a completed or failed CommandExecution item with duration and output, and sends it through handle_exec_end.

Call relations: Tests usually call it after begin_exec or begin_exec_with_source. It requires a command-execution item and panics if given the wrong kind.

Call graph: calls 1 internal fn (handle_exec_end); 2 external calls (format!, panic!).

fn handle_exec_end(chat: &mut ChatWidget, item: AppServerThreadItem)

Purpose: Sends a completed thread item into the widget. For command tests, this represents the server saying the command finished.

Data flow: It receives an item, wraps it in an ItemCompleted notification with current thread and turn ids, and sends it to the widget.

Call relations: end_exec uses it after constructing the final command item. Other tests can call it with any completed item they build.

Call graph: calls 1 internal fn (thread_id); called by 1 (end_exec); 2 external calls (ItemCompleted, handle_server_notification).

fn active_blob(chat: &ChatWidget) -> String

Purpose: Returns the current active transcript cell as plain text. The active cell is the live item currently being updated.

Data flow: It reads the widget’s active cell, renders it at width 80, converts the rendered lines into one string, and returns it. It fails if there is no active cell.

Call relations: It uses lines_to_single_string and is used by tests to snapshot live assistant, command, or tool output.

Call graph: calls 1 internal fn (lines_to_single_string).

fn active_hook_blob(chat: &ChatWidget) -> String

Purpose: Returns the current live hook cell as plain text. If there is no hook cell, it returns a clear empty marker.

Data flow: It checks chat.active_hook_cell. If present, it renders the cell at width 80 and converts it to a string; otherwise it returns "<empty>\n".

Call relations: Hook tests use it to inspect hook display before hook output is committed to history.

Call graph: calls 1 internal fn (lines_to_single_string).

fn expire_quiet_hook_linger(chat: &mut ChatWidget)

Purpose: Forces quiet hook display linger time to expire in tests. This avoids waiting for real time to pass.

Data flow: It mutates the active hook cell, if present, to expire quiet runs immediately, then calls pre_draw_tick so the widget refreshes its display state.

Call relations: Tests use it when they need deterministic hook visibility timing.

Call graph: calls 1 internal fn (pre_draw_tick).

fn reveal_running_hooks(chat: &mut ChatWidget)

Purpose: Forces running hooks to become visible immediately. This makes hook tests deterministic.

Data flow: It mutates the active hook cell, if present, to reveal running runs now, then asks the widget to do its pre-draw update.

Call relations: assert_hook_events_snapshot uses it after starting a hook so the live hook cell can be asserted without waiting.

Call graph: calls 1 internal fn (pre_draw_tick); called by 1 (assert_hook_events_snapshot).

fn reveal_running_hooks_after_delayed_redraw(chat: &mut ChatWidget)

Purpose: Forces running hooks to reveal as if a delayed redraw happened. This tests the delayed-display path without real waiting.

Data flow: It updates the active hook cell’s test timing state, then calls pre_draw_tick so the widget applies the change.

Call relations: Tests use it for hook timing behavior that depends on redraw scheduling.

Call graph: calls 1 internal fn (pre_draw_tick).

fn get_available_model(chat: &ChatWidget, model: &str) -> ModelPreset

Purpose: Finds a named model preset in the widget’s catalog. It fails loudly if the model is missing.

Data flow: It reads the catalog’s model list, searches for the requested model name, clones the matching preset, and returns it. If the catalog cannot be read or the model is absent, the test fails.

Call relations: Tests use it after setting up or modifying the catalog to inspect exact model properties.

async fn assert_shift_left_edits_most_recent_queued_message_for_terminal(
    terminal_info: TerminalInfo,
)

Purpose: Runs a full assertion that Shift+Left edits the newest queued message for a given terminal type. It captures a specific keyboard behavior test.

Data flow: It creates a widget, configures the queued-message edit key binding for the terminal, marks a task as running, queues two messages, simulates Shift+Left, and asserts that the composer now contains the newest message while the older one remains queued.

Call relations: It uses make_chatwidget_manual for setup and is called by terminal-specific tests that want the same behavior checked across terminal environments.

Call graph: calls 2 internal fn (make_chatwidget_manual, from); 2 external calls (new, assert_eq!).

fn render_bottom_first_row(chat: &ChatWidget, width: u16) -> String

Purpose: Renders the widget and returns the first non-empty row. This helps tests inspect compact bottom-pane output.

Data flow: It asks the widget for its desired height at a given width, renders into an in-memory terminal buffer, scans rows from top to bottom, and returns the first row with visible text.

Call relations: Tests use it when they only care about the first visible line rather than the whole rendered popup.

Call graph: 5 external calls (empty, new, new, desired_height, render).

fn render_bottom_popup(chat: &ChatWidget, width: u16) -> String

Purpose: Renders the widget’s bottom area and returns the visible popup text. It trims empty border space around the output.

Data flow: It creates a buffer sized from the widget’s desired height and supplied width, renders the widget, converts every buffer row to text, trims empty leading and trailing rows, and joins the remaining rows with newlines.

Call relations: render_loaded_plugins_popup uses it after loading plugin data. Other tests use it for snapshotting popup UI.

Call graph: called by 1 (render_loaded_plugins_popup); 4 external calls (empty, new, desired_height, render).

fn strip_osc8_for_snapshot(text: &str) -> String

Purpose: Removes terminal hyperlink escape sequences from text before snapshot comparison. OSC 8 is a terminal control format for clickable links.

Data flow: It walks through the string byte by byte. When it sees an OSC 8 escape sequence, it skips it until its terminator; otherwise it copies visible characters into a new string.

Call relations: Tests use it when snapshots should compare what a user sees, not hidden terminal hyperlink codes.

Call graph: 1 external calls (with_capacity).

fn plugins_test_absolute_path(path: &str) -> AbsolutePathBuf

Purpose: Builds an absolute temporary path for plugin-related test data. This avoids using real plugin directories.

Data flow: It starts from the system temporary directory, appends a fixed plugin-test folder and the requested relative path, converts it to an absolute path, and returns it.

Call relations: Plugin summary, detail, and marketplace helpers call this to create realistic but safe paths.

Call graph: called by 4 (plugins_test_curated_marketplace, plugins_test_detail, plugins_test_repo_marketplace, plugins_test_summary); 1 external calls (temp_dir).

fn plugins_test_interface(
    display_name: Option<&str>,
    short_description: Option<&str>,
    long_description: Option<&str>,
) -> PluginInterface

Purpose: Creates plugin interface metadata for tests. Interface metadata is the user-facing name, descriptions, icons, links, and similar fields.

Data flow: It receives optional display name and descriptions, converts present values to strings, fills all other interface fields with empty or None values, and returns the PluginInterface.

Call relations: Plugin summary helpers use it to attach display metadata to fake plugins.

Call graph: called by 2 (plugins_test_remote_summary, plugins_test_summary); 1 external calls (new).

fn plugins_test_summary(
    id: &str,
    name: &str,
    display_name: Option<&str>,
    description: Option<&str>,
    installed: bool,
    enabled: bool,
    install_policy: PluginInstallPolicy,
)

Purpose: Creates a fake local plugin summary. A summary is the short listing shown in plugin menus or marketplaces.

Data flow: It receives identity, display, install, enabled, and policy details, builds a local plugin source path, attaches interface metadata, and returns a PluginSummary.

Call relations: Tests use it to build local plugin lists, often before wrapping them in marketplace or response helpers.

Call graph: calls 2 internal fn (plugins_test_absolute_path, plugins_test_interface); 2 external calls (new, format!).

fn plugins_test_remote_summary(
    remote_plugin_id: &str,
    name: &str,
    display_name: Option<&str>,
    description: Option<&str>,
    installed: bool,
) -> PluginSummary

Purpose: Creates a fake remote plugin summary. Remote plugins come from a marketplace rather than a local path.

Data flow: It receives remote id, name, optional display fields, and installed flag, fills the summary with remote source and available policy, and returns it.

Call relations: Tests use it when checking marketplace behavior for plugins that may need installation.

Call graph: calls 1 internal fn (plugins_test_interface); 1 external calls (new).

fn plugins_test_curated_marketplace(
    plugins: Vec<PluginSummary>,
) -> PluginMarketplaceEntry

Purpose: Wraps plugins in a fake curated ChatGPT marketplace entry. This represents the official curated marketplace in tests.

Data flow: It receives plugin summaries, creates a marketplace name, path, display name, and plugin list, then returns the PluginMarketplaceEntry.

Call relations: Tests combine this with plugins_test_response to simulate a loaded curated marketplace.

Call graph: calls 1 internal fn (plugins_test_absolute_path).

fn plugins_test_repo_marketplace(plugins: Vec<PluginSummary>) -> PluginMarketplaceEntry

Purpose: Wraps plugins in a fake repository marketplace entry. This represents plugins found from the project or repo.

Data flow: It receives plugin summaries, assigns a repo marketplace name and path, adds display metadata, and returns the entry.

Call relations: Tests use it alongside curated marketplace helpers to check how multiple plugin sources are shown.

Call graph: calls 1 internal fn (plugins_test_absolute_path).

fn plugins_test_response(
    marketplaces: Vec<PluginMarketplaceEntry>,
) -> PluginListResponse

Purpose: Creates a fake plugin-list response from marketplace entries. This is the server-style response the widget expects.

Data flow: It receives marketplaces, places them into a PluginListResponse, and fills errors and featured plugin ids as empty lists.

Call relations: render_loaded_plugins_popup and plugin menu tests use it as input to the widget’s plugin-loading path.

Call graph: 1 external calls (new).

fn render_loaded_plugins_popup(
    chat: &mut ChatWidget,
    response: PluginListResponse,
) -> String

Purpose: Loads fake plugin data into a ChatWidget and returns the rendered plugin popup. This combines setup, widget update, and rendering in one helper.

Data flow: It receives a mutable widget and plugin response, tells the widget plugins loaded for the current working directory, asks it to add plugin output, renders the bottom popup at width 100, and returns the text.

Call relations: It uses render_bottom_popup after driving the widget through on_plugins_loaded and add_plugins_output.

Call graph: calls 1 internal fn (render_bottom_popup); 2 external calls (add_plugins_output, on_plugins_loaded).

fn plugins_test_detail(
    summary: PluginSummary,
    description: Option<&str>,
    skills: &[&str],
    hooks: &[(codex_app_server_protocol::HookEventName, usize)],
    apps: &[&str],
    mcp_serv

Purpose: Creates detailed fake plugin information. Details include description, skills, hooks, apps, and MCP server names.

Data flow: It receives a summary and lists of detail fields, builds skill summaries with paths, expands hook event counts into hook summaries, creates app summaries, copies MCP server names, and returns a PluginDetail.

Call relations: Plugin detail tests use it after selecting a plugin summary to simulate the richer information shown on a detail screen.

Call graph: calls 1 internal fn (plugins_test_absolute_path); 2 external calls (new, iter).

fn plugins_test_popup_row_position(popup: &str, needle: &str) -> usize

Purpose: Finds where a piece of text appears inside a rendered plugin popup. It fails if the text is missing.

Data flow: It receives popup text and a search string, returns the byte position where the search string begins, or panics with the full popup for easier debugging.

Call relations: Tests use positions from this helper to assert ordering inside rendered plugin popups.

fn type_plugins_search_query(chat: &mut ChatWidget, query: &str)

Purpose: Types a search query into the ChatWidget one character at a time. This simulates real keyboard input.

Data flow: It receives a mutable widget and query string, turns each character into a key event, and feeds each event to the widget.

Call relations: Plugin search tests use it after opening a plugin popup to filter results through the normal key-handling path.

Call graph: 3 external calls (Char, from, handle_key_event).

fn handle_hook_started(chat: &mut ChatWidget, run: AppServerHookRunSummary)

Purpose: Simulates a hook run starting. Hooks are configured actions that run at certain chat or tool events.

Data flow: It receives a hook run summary, wraps it in a HookStarted notification with current thread id and no turn id, and sends it to the widget.

Call relations: assert_hook_events_snapshot calls it to start the hook lifecycle before checking live hook display.

Call graph: calls 1 internal fn (thread_id); called by 1 (assert_hook_events_snapshot); 2 external calls (HookStarted, handle_server_notification).

fn handle_hook_completed(chat: &mut ChatWidget, run: AppServerHookRunSummary)

Purpose: Simulates a hook run completing. This lets tests check how hook results move into history or warnings.

Data flow: It receives a hook run summary, wraps it in a HookCompleted notification with current thread id, and sends it to the widget.

Call relations: assert_hook_events_snapshot calls it after a started hook to finish the lifecycle.

Call graph: calls 1 internal fn (thread_id); called by 1 (assert_hook_events_snapshot); 2 external calls (HookCompleted, handle_server_notification).

fn hook_run(
    run_id: &str,
    event_name: codex_app_server_protocol::HookEventName,
    status: codex_app_server_protocol::HookRunStatus,
    status_message: &str,
    entries: Vec<codex_app_serv

Purpose: Builds a fake hook run summary with realistic timing and output entries. It can represent running, completed, failed, blocked, or stopped runs.

Data flow: It receives run id, event name, status, status message, and output entries. It fills source, handler, mode, scope, timestamps, duration for final states, and returns the HookRunSummary.

Call relations: assert_hook_events_snapshot uses it to create both running and completed versions of the same hook run.

Call graph: called by 1 (assert_hook_events_snapshot); 2 external calls (from, matches!).

async fn assert_hook_events_snapshot(
    event_name: codex_app_server_protocol::HookEventName,
    run_id: &str,
    status_message: &str,
    snapshot_name: &str,
)

Purpose: Runs a complete hook-event snapshot test. It verifies both live hook display and final history output for one hook event type.

Data flow: It creates a widget, sends a running hook event, confirms no history cell was inserted yet, forces the live hook visible, checks the live text, then sends a completed hook with warning and context entries, drains history, and snapshots the combined rendered output.

Call relations: It orchestrates make_chatwidget_manual, hook_run, handle_hook_started, reveal_running_hooks, handle_hook_completed, drain_insert_history, and rendering helpers into one reusable assertion.

Call graph: calls 6 internal fn (drain_insert_history, handle_hook_completed, handle_hook_started, hook_run, make_chatwidget_manual, reveal_running_hooks); 4 external calls (new, assert!, assert_chatwidget_snapshot!, vec!).

fn hook_event_label(event_name: codex_app_server_protocol::HookEventName) -> &'static str

Purpose: Returns the display label for a hook event name. This keeps expected hook text in tests aligned with event variants.

Data flow: It receives a HookEventName enum value and returns the matching static string such as PreToolUse or SessionStart.

Call relations: assert_hook_events_snapshot uses it when checking that the live hook cell contains the expected running-hook label.

async fn make_test_app() -> App

Purpose: Builds a ready-to-use App for unit tests. It gives tests a realistic app-shaped object while replacing outside-world dependencies with offline or test-safe versions.

Data flow: It starts by making a test chat widget and taking its configuration and event sender. From that configuration it creates file search, picks an offline test model, and builds test telemetry. It then returns a full App with those real test pieces plus many default, empty, or disabled fields, so the result is usable without launching the real terminal app.

Call relations: Many app tests call this when they need a complete App before checking behavior such as config refresh, resume fallback, thread inventory, or app enablement rules. During construction it asks test_session_telemetry to create the telemetry portion, and it also relies on test-support constructors and default builders from nearby modules to keep the fixture isolated from real services.

Call graph: calls 8 internal fn (default, without_managed_config_for_tests, default_for_tests, new, get_model_offline_for_tests, test_session_telemetry, new, defaults); called by 18 (mcp_inventory_omits_thread_id_for_closed_agent_thread, overridden_disabled_guardian_does_not_apply_auto_review_companions, rebuild_config_for_resume_or_fallback_errors_when_cwd_changes, rebuild_config_for_resume_or_fallback_uses_current_config_on_same_cwd_error, refresh_in_memory_config_from_disk_best_effort_keeps_current_config_on_error, refresh_in_memory_config_from_disk_keeps_cloud_requirements_for_thread_transitions, refresh_in_memory_config_from_disk_loads_latest_apps_state, refresh_in_memory_config_from_disk_updates_resize_reflow_config, refresh_in_memory_config_from_disk_uses_active_chat_widget_cwd, sync_tui_pet_disabled_updates_chat_widget_config_copy (+8 more)); 13 external calls (new, new, new, new, new, default, make_chatwidget_manual_with_sender, default, default, default (+3 more)).

fn test_session_telemetry(config: &Config, model: &str) -> SessionTelemetry

Purpose: Creates session telemetry suitable for tests. Telemetry here means the identifying information the app would normally attach to a session, but filled with harmless test values.

Data flow: It receives the current Config and a model name. It converts the config into the form needed by the model manager, builds offline model information, then creates and returns a SessionTelemetry value with a fresh thread ID, the model details, no account information, a test originator, and a fixed session source.

Call relations: This helper is used by make_test_app while assembling the test App. It hands back the telemetry object that the app expects to have, without requiring a logged-in account or a real model lookup.

Call graph: calls 3 internal fn (construct_model_info_offline_for_tests, new, new); called by 1 (make_test_app); 3 external calls (to_models_manager_config, from_value, json!).

fn app_enabled_in_effective_config(config: &Config, app_id: &str) -> Option<bool>

Purpose: Looks up whether a named app is marked as enabled in the final, effective configuration. Tests use it to confirm what the configuration says after all config layers have been combined.

Data flow: It receives a Config and an app ID string. It walks through the effective configuration as nested TOML tables, looking for apps, then the named app, then its enabled value. It returns Some(true) or Some(false) if that boolean is present, and None if any part of the path is missing or not the expected shape.

Call relations: This is a small assertion helper for tests that inspect app configuration. Unlike make_test_app, it does not build anything; it reads the already-merged config and gives tests a simple answer about one app's enabled flag.

fn test_absolute_path(path: &str) -> AbsolutePathBuf

Purpose: Creates an absolute path value for tests. It is used when a test needs to feed the app a path in the same strict format the real code expects.

Data flow: A path string goes in, it is turned into a path buffer and checked as absolute, and an absolute-path object comes out.

Call relations: Permission and settings tests call this helper when building fake server requests that include file-system paths.

Call graph: calls 1 internal fn (try_from); called by 2 (inactive_thread_permissions_approval_preserves_file_system_permissions, inactive_thread_settings_notification_updates_cached_collaboration_mode); 1 external calls (from).

async fn next_thread_settings_updated(
    app_server: &mut AppServerSession,
    thread_id: ThreadId,
) -> ThreadSettingsUpdatedNotification

Purpose: Waits for the next thread-settings update notification for a specific thread. It helps tests ignore unrelated app-server events.

Data flow: An app-server session and thread id go in; the function reads events until it finds the matching settings update, then returns that notification or panics if it never appears.

Call relations: The thread-settings override test uses this after submitting a settings change, so it can verify the server emitted the expected update.

Call graph: calls 1 internal fn (next_event); called by 1 (override_turn_context_sends_thread_settings_update); 4 external calls (panic!, to_string, from_secs, timeout).

async fn handle_mcp_inventory_result_respects_origin_thread()

Purpose: Checks that MCP inventory results only affect the thread they belong to. MCP means Model Context Protocol, a way external tool servers are reported to the app.

Data flow: The test creates loading UI cells, sends inventory results with and without matching thread ids, and checks whether the loading cell is removed.

Call relations: It exercises the app’s MCP inventory result path directly to make sure cross-thread results do not erase another thread’s UI.

Call graph: calls 2 internal fn (new, make_test_app); 5 external calls (new, new, assert_eq!, new_mcp_inventory_loading, vec!).

fn bypass_hook_trust_startup_warning_snapshot()

Purpose: Locks down the exact warning text shown when hook trust is dangerously bypassed. The snapshot catches accidental wording or formatting changes.

Data flow: A warning history cell is rendered to plain text, then compared with a saved snapshot.

Call relations: It relies on the shared line-rendering helper and the snapshot macro used throughout this test file.

Call graph: calls 1 internal fn (lines_to_single_string); 2 external calls (assert_app_snapshot!, new_warning_event).

async fn enqueue_primary_thread_session_replays_buffered_approval_after_attach() -> Result<()>

Purpose: Verifies that an approval request received before the primary thread is attached is replayed afterward and can still be answered.

Data flow: A fake approval is buffered, a thread session is attached, the buffered event is read, and pressing y produces a thread-scoped operation.

Call relations: It combines the test-app builder, approval helper, and thread-session helper to test the app’s primary-thread attach flow.

Call graph: calls 4 internal fn (new, exec_approval_request, make_test_app_with_channels, test_thread_session); 8 external calls (from_millis, Char, new, new, assert!, assert_eq!, panic!, timeout).

async fn resolved_buffered_approval_does_not_become_actionable_after_drain() -> Result<()>

Purpose: Ensures an approval that was already resolved does not become clickable again when its buffered event is later drained.

Data flow: The test enqueues and resolves an approval, drains the buffered event, simulates accepting it, and confirms no submit operation is emitted.

Call relations: It checks the same buffering path as the prior approval test, but covers the resolved-request edge case.

Call graph: calls 4 internal fn (new, exec_approval_request, make_test_app_with_channels, test_thread_session); 8 external calls (Integer, from_millis, Char, new, new, assert!, assert_eq!, timeout).

async fn enqueue_primary_thread_session_replays_turns_before_initial_prompt_submit() -> Result<()>

Purpose: Checks that restored history appears before an initial prompt is submitted. This prevents the first visible action from looking out of order.

Data flow: A new chat widget with an initial prompt is installed, a previous turn is replayed, and emitted events are inspected for both history insertion and prompt submission.

Call relations: It uses the model and thread helpers to exercise primary thread startup replay plus initial user-message submission.

Call graph: calls 7 internal fn (new, get_model_offline_for_tests, new, lines_to_single_string, make_test_app_with_channels, test_thread_session, test_dummy); 6 external calls (new, assert!, assert_eq!, create_initial_user_message, new_with_app_event, vec!).

async fn reset_thread_event_state_aborts_listener_tasks()

Purpose: Confirms that resetting thread event state stops background listener tasks. A listener task is an async job waiting for thread events.

Data flow: A never-ending task is inserted, reset is called, and a drop notification proves the task was aborted and removed.

Call relations: It directly tests cleanup behavior that protects the app from leaving old event readers running.

Call graph: calls 2 internal fn (new, make_test_app); 5 external calls (from_millis, assert_eq!, timeout, spawn, channel).

async fn history_lookup_response_is_routed_to_requesting_thread() -> Result<()>

Purpose: Checks that a message-history lookup response keeps the thread id that requested it.

Data flow: The app starts a lookup for one thread, receives an app event, and verifies the response event names the same thread and lookup details.

Call relations: It exercises the app event routing path used when the UI asks for older history.

Call graph: calls 2 internal fn (new, make_test_app_with_channels); 5 external calls (from_secs, assert!, assert_eq!, panic!, timeout).

async fn enqueue_thread_event_does_not_block_when_channel_full() -> Result<()>

Purpose: Ensures adding thread events will not hang if a per-thread channel is full.

Data flow: A tiny channel is filled, another event is enqueued under a timeout, and both events are later read back.

Call relations: It tests the thread-notification enqueue path using the thread-closed notification helper.

Call graph: calls 4 internal fn (new, make_test_app, thread_closed_notification, new); 2 external calls (from_millis, timeout).

async fn replay_thread_snapshot_restores_draft_and_queued_input()

Purpose: Verifies that switching away from and back to a thread restores the draft text without accidentally submitting queued input.

Data flow: The test captures input state, stores it in a thread snapshot, replaces the chat widget, replays the snapshot, and checks the composer and outgoing operations.

Call relations: It uses the thread-session helper and manual chat-widget factory to test snapshot replay in isolation.

Call graph: calls 4 internal fn (new, make_test_app, test_thread_session, new_with_session); 4 external calls (new, assert!, assert_eq!, make_chatwidget_manual_with_sender).

async fn active_turn_id_for_thread_uses_snapshot_turns()

Purpose: Checks that the app can find a thread’s active turn from cached snapshot data.

Data flow: A thread channel is seeded with an in-progress turn, and the lookup returns that turn id.

Call relations: It relies on the shared test session and turn helper to validate per-thread state lookup.

Call graph: calls 4 internal fn (new, make_test_app, test_thread_session, new_with_session); 2 external calls (assert_eq!, vec!).

async fn replayed_turn_complete_submits_restored_queued_follow_up()

Purpose: Ensures a queued follow-up message is submitted after replay proves the prior turn completed.

Data flow: A running turn and queued input are captured, replayed with a completion event, and the outgoing user-turn operation is checked.

Call relations: It uses notification helpers and next_user_turn_op to verify replay triggers the same submission path as live completion.

Call graph: calls 6 internal fn (new, agent_message_delta_notification, make_test_app_with_channels, next_user_turn_op, test_thread_session, turn_started_notification); 6 external calls (new, new, assert_eq!, make_chatwidget_manual_with_sender, panic!, vec!).

async fn replay_only_thread_keeps_restored_queue_visible()

Purpose: Checks that replay-only threads show restored queued input but do not submit it.

Data flow: A queued follow-up is captured, replayed with completion while auto-resume is disabled, and the queue remains visible with no outgoing operation.

Call relations: It tests snapshot replay behavior for read-only or non-live thread views.

Call graph: calls 5 internal fn (new, agent_message_delta_notification, make_test_app_with_channels, test_thread_session, turn_started_notification); 6 external calls (new, new, assert!, assert_eq!, make_chatwidget_manual_with_sender, vec!).

async fn replay_thread_snapshot_keeps_queue_when_running_state_only_comes_from_snapshot()

Purpose: Ensures queued input stays queued if replay does not show the running turn has finished.

Data flow: Captured queued input is replayed without completion evidence, and the test checks that nothing is submitted.

Call relations: It guards the replay logic against treating missing events as permission to send a queued message.

Call graph: calls 5 internal fn (new, agent_message_delta_notification, make_test_app_with_channels, test_thread_session, turn_started_notification); 6 external calls (new, new, assert!, assert_eq!, make_chatwidget_manual_with_sender, vec!).

async fn replay_thread_snapshot_in_progress_turn_restores_running_queue_state()

Purpose: Verifies that an in-progress turn in snapshot data keeps follow-up input queued.

Data flow: A snapshot with an in-progress turn and saved queue state is replayed, leaving the queued text in place and producing no user-turn operation.

Call relations: It covers the snapshot-turn version of the same running-state decision tested elsewhere with replayed events.

Call graph: calls 5 internal fn (new, agent_message_delta_notification, make_test_app_with_channels, test_thread_session, turn_started_notification); 6 external calls (new, new, assert!, assert_eq!, make_chatwidget_manual_with_sender, vec!).

async fn replay_thread_snapshot_in_progress_turn_restores_running_state_without_input_state()

Purpose: Checks that replaying an in-progress turn marks the chat widget as running even if no draft or queue was saved.

Data flow: A fresh widget receives a snapshot containing only an in-progress turn, and the test confirms the task-running flag is set.

Call relations: It focuses on the chat widget state restored by app snapshot replay.

Call graph: calls 3 internal fn (new, make_test_app_with_channels, test_thread_session); 4 external calls (new, assert!, make_chatwidget_manual_with_sender, vec!).

async fn replay_thread_snapshot_does_not_submit_queue_before_replay_catches_up()

Purpose: Ensures queued input waits for the latest replayed turn to complete, not just any earlier turn.

Data flow: Replay includes an older completion and a newer start, the queue remains held, then a live completion submits the follow-up.

Call relations: It combines replay helpers with live notification handling to test the handoff from replay to active thread updates.

Call graph: calls 7 internal fn (new, agent_message_delta_notification, make_test_app_with_channels, next_user_turn_op, test_thread_session, turn_completed_notification, turn_started_notification); 7 external calls (new, new, assert!, assert_eq!, make_chatwidget_manual_with_sender, panic!, vec!).

async fn replay_thread_snapshot_restores_pending_pastes_for_submit()

Purpose: Verifies that a large pasted draft survives thread switching and can be submitted afterward.

Data flow: A large paste is captured in input state, replayed into a new widget, then Enter produces a user-turn operation containing the pasted text.

Call relations: It uses next_user_turn_op to confirm restored paste data flows into normal submission.

Call graph: calls 5 internal fn (new, make_test_app_with_channels, next_user_turn_op, test_thread_session, new_with_session); 5 external calls (new, new, assert_eq!, make_chatwidget_manual_with_sender, panic!).

async fn replay_thread_snapshot_restores_collaboration_mode_for_draft_submit()

Purpose: Checks that a saved draft remembers its collaboration mode, model, and reasoning effort when later submitted.

Data flow: A draft is saved under one mode, replayed into a widget currently set to another mode, and submission uses the restored mode settings.

Call relations: It protects thread-specific input state from being overwritten by whichever settings are active at replay time.

Call graph: calls 4 internal fn (new, make_test_app_with_channels, next_user_turn_op, test_thread_session); 6 external calls (new, new, assert_eq!, make_chatwidget_manual_with_sender, panic!, vec!).

async fn replay_thread_snapshot_restores_collaboration_mode_without_input()

Purpose: Ensures collaboration settings restore even when there is no text draft.

Data flow: A settings-only input state is replayed, and the widget’s active mode, model, and effort are checked.

Call relations: It complements the draft-submit test by covering pure settings restoration.

Call graph: calls 3 internal fn (new, make_test_app_with_channels, test_thread_session); 4 external calls (new, assert_eq!, make_chatwidget_manual_with_sender, vec!).

async fn replayed_interrupted_turn_restores_queued_input_to_composer()

Purpose: Checks that if a turn was interrupted, queued follow-up text returns to the composer for editing instead of being submitted.

Data flow: Queued input is captured, replay reports the turn interrupted, and the text appears in the composer with no outgoing operation.

Call relations: It tests the replay branch for interrupted turns using the same notification and session helpers as the queue tests.

Call graph: calls 5 internal fn (new, agent_message_delta_notification, make_test_app_with_channels, test_thread_session, turn_started_notification); 6 external calls (new, new, assert!, assert_eq!, make_chatwidget_manual_with_sender, vec!).

async fn token_usage_update_refreshes_status_line_with_runtime_context_window()

Purpose: Verifies that token-usage notifications update the status line with the model’s context-window size.

Data flow: The status line starts empty, a token-usage event with a context window is handled, and the status text changes.

Call relations: It uses the token-usage notification helper to exercise live thread event handling.

Call graph: calls 3 internal fn (new, make_test_app, token_usage_notification); 3 external calls (assert_eq!, Notification, vec!).

async fn collab_receiver_notification_caches_thread_without_app_server_read()

Purpose: Checks that a collaboration tool call mentioning a receiver thread creates navigation metadata without reading that thread from the server.

Data flow: A fake collab item-started notification is handled, and the receiver thread appears in agent navigation with placeholder metadata.

Call relations: It tests passive discovery of agent threads from collaboration notifications.

Call graph: calls 3 internal fn (from_string, new, make_test_app); 5 external calls (new, ItemStarted, assert_eq!, Notification, vec!).

async fn collab_receiver_notification_does_not_cache_not_found_thread()

Purpose: Ensures a receiver thread marked not found is not added to agent navigation.

Data flow: A failed collab item-completed notification with a not-found receiver is handled, and navigation remains empty for that thread.

Call relations: It covers the negative case for the collaboration receiver caching logic.

Call graph: calls 3 internal fn (from_string, new, make_test_app); 5 external calls (from, ItemCompleted, assert_eq!, Notification, vec!).

async fn open_agent_picker_keeps_missing_threads_for_replay() -> Result<()>

Purpose: Checks that opening the agent picker keeps locally cached threads even if the server cannot currently read them.

Data flow: A local thread channel is inserted, the picker opens, and the thread remains listed as closed for replay.

Call relations: It exercises the picker refresh path with an embedded test app server.

Call graph: calls 3 internal fn (new, make_test_app, new); 3 external calls (pin, assert_eq!, start_embedded_app_server_for_picker).

async fn open_agent_picker_preserves_cached_metadata_for_replay_threads() -> Result<()>

Purpose: Ensures replay-only agent threads keep their cached nickname and role when the picker refreshes.

Data flow: Cached metadata is inserted, the picker opens, and the metadata is still present.

Call relations: It protects user-facing labels from being erased during agent-picker refresh.

Call graph: calls 3 internal fn (new, make_test_app, new); 3 external calls (pin, assert_eq!, start_embedded_app_server_for_picker).

async fn open_agent_picker_clears_completed_path_backed_agent_running_state() -> Result<()>

Purpose: Checks that an agent thread with completed cached turns is no longer shown as running.

Data flow: A channel is seeded with start and completion events, agent activity says running, and picker refresh clears the running flag.

Call relations: It ties thread snapshot liveness to the agent navigation display.

Call graph: calls 5 internal fn (new, make_test_app, turn_completed_notification, turn_started_notification, new); 3 external calls (pin, assert_eq!, start_embedded_app_server_for_picker).

async fn open_agent_picker_refreshes_replay_only_path_backed_liveness() -> Result<()>

Purpose: Ensures replay-only path-backed agents are shown as closed even if their cached events suggest they were running.

Data flow: A replay-only channel with a started turn is refreshed through the picker, and navigation marks it closed and not running.

Call relations: It tests how replay-only status overrides cached activity hints.

Call graph: calls 4 internal fn (new, make_test_app, turn_started_notification, new); 3 external calls (pin, assert_eq!, start_embedded_app_server_for_picker).

async fn open_agent_picker_prunes_terminal_metadata_only_threads() -> Result<()>

Purpose: Checks that stale agent metadata with no backing thread state is removed.

Data flow: Navigation is seeded with a ghost thread, picker refresh runs, and the entry disappears.

Call relations: It covers cleanup in the agent picker’s refresh cycle.

Call graph: calls 2 internal fn (new, make_test_app); 4 external calls (pin, assert!, assert_eq!, start_embedded_app_server_for_picker).

async fn open_agent_picker_marks_terminal_read_errors_closed() -> Result<()>

Purpose: Verifies that a thread read failure leaves the cached thread available as closed rather than active.

Data flow: A local channel and metadata are inserted, picker refresh fails to load it, and the entry is marked closed.

Call relations: It protects replay access for threads the server cannot read live.

Call graph: calls 3 internal fn (new, make_test_app, new); 3 external calls (pin, assert_eq!, start_embedded_app_server_for_picker).

fn open_agent_picker_marks_loaded_threads_open() -> Result<()>

Purpose: Checks that a thread successfully loaded from the server is marked open in the picker.

Data flow: A real embedded-server thread is started, locally cached, picker refresh runs, and navigation marks it not closed.

Call relations: It uses its own Tokio runtime to test the app-server-backed picker flow.

Call graph: calls 2 internal fn (make_test_app, new); 4 external calls (pin, assert_eq!, start_embedded_app_server_for_picker, new_multi_thread).

fn attach_live_thread_for_selection_rejects_empty_non_ephemeral_fallback_threads() -> Result<()>

Purpose: Ensures the app does not attach a blank fallback for a live non-ephemeral thread that has no replay material yet.

Data flow: A server thread is created but not materialized in local state, attach is attempted, and an explanatory error is returned.

Call relations: It tests agent-picker selection attach behavior against a real embedded server.

Call graph: calls 1 internal fn (make_test_app); 4 external calls (assert!, assert_eq!, start_embedded_app_server_for_picker, new_multi_thread).

fn attach_live_thread_for_selection_rejects_unmaterialized_fallback_threads() -> Result<()>

Purpose: Ensures an ephemeral fallback thread also cannot be attached as a blank live view.

Data flow: An ephemeral server thread is started, attach is attempted, and the app rejects it without adding a local channel.

Call relations: It complements the non-ephemeral rejection test for side or temporary threads.

Call graph: calls 1 internal fn (make_test_app); 4 external calls (assert!, assert_eq!, start_embedded_app_server_for_picker, new_multi_thread).

async fn should_attach_live_thread_for_selection_skips_closed_metadata_only_threads()

Purpose: Checks the quick decision for whether picker selection should try a live attach.

Data flow: The test toggles metadata between closed, open, and already cached states, and checks the boolean decision each time.

Call relations: It directly exercises the lightweight guard used before attempting a server attach.

Call graph: calls 3 internal fn (new, make_test_app, new); 1 external calls (assert!).

async fn refresh_agent_picker_thread_liveness_prunes_closed_metadata_only_threads() -> Result<()>

Purpose: Verifies that refreshing a metadata-only thread removes it when it is not available.

Data flow: A ghost navigation entry is refreshed against the server, returns unavailable, and is removed from navigation and channels.

Call relations: It tests the single-thread refresh helper used by the picker.

Call graph: calls 2 internal fn (new, make_test_app); 4 external calls (pin, assert!, assert_eq!, start_embedded_app_server_for_picker).

async fn open_agent_picker_prompts_to_enable_multi_agent_when_disabled() -> Result<()>

Purpose: Checks that opening the agent picker while multi-agent support is disabled offers to enable it.

Data flow: The feature is disabled, the picker opens, Enter is pressed, and events request enabling plus show an informational history cell.

Call relations: It exercises picker UI behavior through the chat widget and app event channel.

Call graph: calls 1 internal fn (make_test_app_with_channels); 6 external calls (pin, new, assert!, assert_matches!, start_embedded_app_server_for_picker, panic!).

async fn update_memory_settings_persists_and_updates_widget_config() -> Result<()>

Purpose: Verifies memory settings are written to config and reflected in both app and widget state.

Data flow: A temp config home is used, settings are changed through the app server, and the in-memory config plus written TOML file are checked.

Call relations: It tests the settings menu path that updates memory behavior.

Call graph: calls 1 internal fn (make_test_app_with_channels); 6 external calls (pin, assert!, assert_eq!, start_embedded_app_server_for_picker, read_to_string, tempdir).

fn update_memory_settings_updates_current_thread_memory_mode() -> Result<()>

Purpose: Checks that changing memory generation updates the current thread’s stored memory mode.

Data flow: A thread is started, memory generation is disabled, and the state database records the thread mode as disabled.

Call relations: It combines config writing, app-server thread state, and the state database.

Call graph: calls 2 internal fn (init, make_test_app_with_channels); 5 external calls (pin, assert_eq!, start_embedded_app_server_for_picker, tempdir, new_multi_thread).

async fn reset_memories_clears_local_memory_directories() -> Result<()>

Purpose: Ensures the reset-memories action deletes local memory files and folders.

Data flow: Fake memory files are created under a temp home, reset runs through the app server, and the memory root becomes empty.

Call relations: It tests the destructive cleanup path used by the UI memory reset command.

Call graph: calls 1 internal fn (make_test_app_with_channels); 6 external calls (pin, assert_eq!, start_embedded_app_server_for_picker, create_dir_all, write, tempdir).

async fn apply_permission_profile_selection_preserves_loader_overrides() -> Result<()>

Purpose: Checks that selecting a permission profile respects the config file path chosen by the loader.

Data flow: A temp config defines a profile, runtime overrides are set, selection is applied, and app/widget config plus emitted operation are verified.

Call relations: It exercises permission profile selection and its notification to the running conversation.

Call graph: calls 2 internal fn (workspace_write, make_test_app_with_channels); 5 external calls (assert!, assert_eq!, panic!, write, tempdir).

async fn update_feature_flags_enabling_guardian_selects_auto_review() -> Result<()>

Purpose: Verifies enabling Guardian Approval also selects the auto-review permission mode.

Data flow: The feature flag is enabled, app and widget configs update, an override operation is emitted, history shows the change, and config TOML is written.

Call relations: It uses the config-write app-server helper shared by Guardian feature tests.

Call graph: calls 2 internal fn (make_test_app_with_channels, start_config_write_test_app_server); 6 external calls (assert!, assert_eq!, panic!, read_to_string, tempdir, vec!).

async fn update_feature_flags_disabling_guardian_clears_review_policy_and_restores_default() -> Result<()>

Purpose: Checks that disabling Guardian Approval removes the reviewer setting and restores user approval behavior.

Data flow: A config with Guardian enabled is seeded, the feature is disabled, runtime state and written TOML are inspected.

Call relations: It validates the rollback side of the Guardian feature toggle flow.

Call graph: calls 4 internal fn (legacy, workspace_write, make_test_app_with_channels, start_config_write_test_app_server); 7 external calls (assert!, assert_eq!, panic!, read_to_string, write, tempdir, vec!).

async fn update_feature_flags_enabling_guardian_overrides_explicit_manual_review_policy() -> Result<()>

Purpose: Ensures enabling Guardian overrides an explicit manual reviewer setting.

Data flow: A config with manual review is seeded, Guardian is enabled, and the resulting config, widget state, operation, and file contents use auto review.

Call relations: It covers precedence rules in the same feature-flag update path.

Call graph: calls 2 internal fn (make_test_app_with_channels, start_config_write_test_app_server); 6 external calls (assert!, assert_eq!, read_to_string, write, tempdir, vec!).

async fn update_feature_flags_disabling_guardian_clears_manual_review_policy_without_history() -> Result<()>

Purpose: Checks that disabling Guardian does not add a history notice when the effective review mode remains the default.

Data flow: Guardian is disabled from a manual-review config, an override operation is emitted, no history event appears, and TOML removes the feature and reviewer keys.

Call relations: It guards against noisy UI updates in the Guardian toggle path.

Call graph: calls 2 internal fn (make_test_app_with_channels, start_config_write_test_app_server); 6 external calls (assert!, assert_eq!, read_to_string, write, tempdir, vec!).

async fn open_agent_picker_allows_existing_agent_threads_when_feature_is_disabled() -> Result<()>

Purpose: Ensures existing agent threads remain selectable even when the multi-agent feature is disabled.

Data flow: A thread channel is present, the picker opens, Enter selects the thread, and a selection app event is emitted.

Call relations: It distinguishes existing replay data from starting new multi-agent functionality.

Call graph: calls 3 internal fn (new, make_test_app_with_channels, new); 4 external calls (pin, new, assert_matches!, start_embedded_app_server_for_picker).

async fn refresh_pending_thread_approvals_only_lists_inactive_threads()

Purpose: Checks that the pending-approval badge lists only approvals from inactive threads.

Data flow: A main and agent thread are created, the agent has a pending approval, and the badge appears until that agent becomes active.

Call relations: It tests the badge refresh logic using the approval helper.

Call graph: calls 4 internal fn (from_string, exec_approval_request, make_test_app, new); 2 external calls (assert!, assert_eq!).

async fn inactive_thread_approval_bubbles_into_active_view() -> Result<()>

Purpose: Verifies an approval in an inactive agent thread can surface in the active view as an actionable prompt.

Data flow: An agent thread with approval-capable settings gets an approval request, and the active chat widget shows an approval view plus badge text.

Call relations: It exercises inactive-thread request queuing and surfacing.

Call graph: calls 7 internal fn (workspace_write, from_string, exec_approval_request, make_test_app, test_thread_session, new, new_with_session); 2 external calls (new, assert_eq!).

async fn side_defers_parent_approval_overlay_until_parent_replay() -> Result<()>

Purpose: Checks that while in a side conversation, a parent-thread approval is noted but not shown until returning to the parent.

Data flow: A parent approval is queued while a side thread is active, side state records needing approval, then parent replay shows the active view.

Call relations: It tests the side-conversation deferral path for parent interactive requests.

Call graph: calls 6 internal fn (from_string, new, exec_approval_request, make_test_app, test_thread_session, new_with_session); 3 external calls (new, assert!, assert_eq!).

async fn replay_snapshot_with_pending_request_suppresses_replay_notices()

Purpose: Ensures replay notices do not cover an approval prompt when a snapshot contains a pending request.

Data flow: A snapshot with a warning and approval request is replayed, the approval view appears, and no replayed warning history is emitted.

Call relations: It guards the replay display order around interactive requests.

Call graph: calls 4 internal fn (from_string, lines_to_single_string, make_test_app_with_channels, test_thread_session); 5 external calls (new, new, assert!, assert_eq!, vec!).

async fn side_defers_subagent_approval_overlay_until_side_exits() -> Result<()>

Purpose: Checks that a subagent approval is not shown as an overlay while a side conversation is active, but appears after leaving side mode.

Data flow: An agent approval is queued during side mode, only the badge appears, then after side exit the pending request surfaces.

Call relations: It exercises inactive-thread approval surfacing with side-thread suppression.

Call graph: calls 7 internal fn (workspace_write, from_string, new, exec_approval_request, make_test_app, test_thread_session, new_with_session); 2 external calls (new, assert_eq!).

async fn inactive_thread_exec_approval_preserves_context()

Purpose: Verifies command-execution approvals keep network and extra permission details when converted for an inactive thread.

Data flow: A fake exec approval is enriched with network and file permissions, converted into a UI request, and all details are checked.

Call relations: It tests the app’s request-localization logic for inactive-thread approvals.

Call graph: calls 3 internal fn (new, exec_approval_request, make_test_app); 3 external calls (assert_eq!, panic!, vec!).

async fn inactive_thread_exec_approval_splits_shell_wrapped_command()

Purpose: Checks that a shell-wrapped command is split into meaningful command parts for display.

Data flow: A joined shell command string goes into an exec approval, conversion produces a vector of command arguments, and the pieces are checked.

Call relations: It covers command formatting in the inactive approval conversion path.

Call graph: calls 3 internal fn (new, exec_approval_request, make_test_app); 3 external calls (assert_eq!, panic!, try_join).

async fn inactive_thread_file_change_approval_recovers_buffered_changes()

Purpose: Ensures a file-change approval can recover the patch preview from earlier buffered file-change events.

Data flow: A file-change item is buffered, an approval request is converted, recovered changes and reason are checked, then the preview cell is rendered.

Call relations: It ties the event store to the approval UI for patch requests.

Call graph: calls 3 internal fn (new, lines_to_single_string, make_test_app_with_channels); 6 external calls (Integer, ItemStarted, assert!, assert_eq!, panic!, vec!).

async fn inactive_thread_permissions_approval_preserves_file_system_permissions()

Purpose: Checks that permission approval requests preserve read and write path permissions.

Data flow: A permissions request with network and file-system entries is converted, and the UI request contains equivalent permission data.

Call relations: It uses test_absolute_path to build strict path values for conversion.

Call graph: calls 3 internal fn (new, make_test_app, test_absolute_path); 4 external calls (Integer, assert_eq!, panic!, vec!).

async fn inactive_thread_url_elicitation_routes_to_app_link()

Purpose: Verifies a valid MCP URL elicitation becomes an app-link prompt.

Data flow: A server asks the user to open an HTTPS URL, conversion returns link parameters with title, server description, URL, and target info.

Call relations: It tests inactive-thread routing for external action requests.

Call graph: calls 2 internal fn (new, make_test_app); 3 external calls (Integer, assert_eq!, panic!).

async fn inactive_thread_invalid_url_elicitation_is_declined()

Purpose: Ensures an unsafe or invalid MCP URL elicitation is declined automatically.

Data flow: A request with an HTTP URL is converted, no UI prompt is returned, and a decline operation is sent for that thread.

Call relations: It covers the safety branch paired with the valid app-link test.

Call graph: calls 2 internal fn (new, make_test_app_with_channels); 3 external calls (Integer, assert!, assert_matches!).

async fn inactive_thread_approval_badge_clears_after_turn_completion_notification() -> Result<()>

Purpose: Checks that an inactive-thread approval badge disappears as soon as that turn completes.

Data flow: An agent approval creates a badge, a completion notification for the same turn is queued, and the badge list becomes empty.

Call relations: It verifies immediate badge cleanup during inactive-thread event handling.

Call graph: calls 8 internal fn (workspace_write, from_string, exec_approval_request, make_test_app, test_thread_session, turn_completed_notification, new, new_with_session); 3 external calls (new, assert!, assert_eq!).

async fn inactive_thread_started_notification_initializes_replay_session() -> Result<()>

Purpose: Ensures a thread-started notification for an inactive agent builds enough session state for later replay.

Data flow: Primary session state and a rollout file are seeded, a thread-started notification arrives, and the cached session inherits model, permissions, roots, path, and agent metadata correctly.

Call relations: It tests session inference for agent threads discovered through notifications.

Call graph: calls 5 internal fn (workspace_write, from_string, make_test_app, test_thread_session, new_with_session); 8 external calls (ThreadStarted, new, assert_eq!, format!, json!, write, tempdir, vec!).

async fn inactive_thread_started_notification_preserves_primary_model_when_path_missing() -> Result<()>

Purpose: Checks that if a started agent thread has no rollout path, the cached session keeps the primary model fallback.

Data flow: A primary session is cached, an agent thread-started notification without a path arrives, and the inferred agent session model matches the primary model.

Call relations: It covers a missing-data case in the same session-inference path.

Call graph: calls 5 internal fn (workspace_write, from_string, make_test_app, test_thread_session, new_with_session); 4 external calls (ThreadStarted, new, assert_eq!, vec!).

async fn thread_read_session_state_does_not_reuse_primary_permission_profile()

Purpose: Verifies thread/read fallback session state does not reuse the primary thread’s permission profile after changing cwd.

Data flow: A primary session is cached, a separate read thread is converted to session state, and its permission profile comes from active widget config instead.

Call relations: It protects replay hydration from carrying unsafe permissions across workspaces.

Call graph: calls 4 internal fn (workspace_write, from_string, make_test_app, test_thread_session); 3 external calls (new, assert_eq!, vec!).

fn agent_picker_item_name_snapshot()

Purpose: Locks down how agent picker display names are formatted.

Data flow: Several nickname/role/primary combinations are formatted with a thread id and compared to a snapshot.

Call relations: It tests the small formatting function used by the picker UI.

Call graph: calls 1 internal fn (from_string); 2 external calls (assert_app_snapshot!, format!).

async fn side_fork_config_is_ephemeral_and_appends_developer_guardrails()

Purpose: Checks that a side-conversation fork is temporary and includes safety instructions.

Data flow: The side fork config is created, and the test confirms it is ephemeral, keeps permissions, and contains guardrail text.

Call relations: It directly tests the config builder used when starting side conversations.

Call graph: calls 1 internal fn (make_test_app); 2 external calls (assert!, assert_eq!).

async fn side_fork_config_inherits_parent_thread_runtime_settings()

Purpose: Ensures side conversations inherit the parent thread’s current runtime model, effort, service tier, permissions, and reviewer.

Data flow: The chat widget is set to parent runtime values, a side fork config is built, and those values are checked.

Call relations: It complements the guardrail test by checking inherited settings.

Call graph: calls 3 internal fn (legacy, workspace_write, make_test_app); 1 external calls (assert_eq!).

async fn side_start_block_message_tracks_open_side_conversation()

Purpose: Checks the message that explains why /side is unavailable.

Data flow: The app starts with no primary thread, then with a primary thread, then with an active side thread, and the block message changes accordingly.

Call relations: It tests the guard used before starting a side conversation.

Call graph: calls 3 internal fn (new, new, make_test_app); 1 external calls (assert_eq!).

async fn side_parent_status_tracks_parent_turn_lifecycle() -> Result<()>

Purpose: Verifies side-thread status notices track whether the parent turn finished, restarted, or failed.

Data flow: Parent turn completion, start, and failure notifications are queued, and side state changes between finished, none, and failed.

Call relations: It uses turn notification helpers to test side-parent status updates.

Call graph: calls 5 internal fn (new, new, make_test_app, turn_completed_notification, turn_started_notification); 1 external calls (assert_eq!).

async fn side_parent_status_prioritizes_input_over_approval() -> Result<()>

Purpose: Checks that when the parent needs both approval and input, the side status shows input as more important.

Data flow: An approval request is queued, then an input request, then each is resolved; the parent status moves from approval to input, back to approval, then clear.

Call relations: It exercises side-parent status updates for server requests and their resolution notifications.

Call graph: calls 5 internal fn (new, new, exec_approval_request, make_test_app, request_user_input_request); 3 external calls (Integer, ServerRequestResolved, assert_eq!).

async fn side_thread_snapshot_hides_forked_parent_transcript()

Purpose: Ensures a side thread snapshot does not replay the parent transcript it was forked from.

Data flow: A side session with a parent turn is installed into an event store, and the stored session has no fork marker or parent turns.

Call relations: It tests the static snapshot installer used for side threads.

Call graph: calls 4 internal fn (new, test_thread_session, test_turn, new); 3 external calls (assert_eq!, install_side_thread_snapshot, vec!).

async fn side_thread_snapshot_does_not_refresh_from_fork_history()

Purpose: Checks that side-thread snapshots are not refreshed from fork history.

Data flow: A side thread is registered, a snapshot with no rollout path is examined, and the app decides not to refresh it.

Call relations: It protects side conversations from pulling in parent history during replay.

Call graph: calls 4 internal fn (new, new, make_test_app, test_thread_session); 2 external calls (new, assert!).

async fn side_thread_snapshot_skips_session_header_preamble()

Purpose: Ensures replaying a side-thread snapshot does not insert the usual session header preamble.

Data flow: A side snapshot is replayed, emitted history cells are collected, and no header or active transcript appears.

Call relations: It tests side-specific replay display behavior through the app event channel.

Call graph: calls 5 internal fn (new, new, lines_to_single_string, make_test_app_with_channels, test_thread_session); 2 external calls (new, assert_eq!).

async fn primary_thread_ignores_child_mcp_startup_notifications()

Purpose: Checks that MCP startup failures for a child thread do not render in the active primary thread.

Data flow: A child-thread MCP failure is handled, no primary UI event appears, the child buffer stores it, and replaying the child shows the warning once.

Call relations: It tests app-server event routing plus later child-thread replay.

Call graph: calls 4 internal fn (new, lines_to_single_string, make_test_app_with_channels, test_thread_session); 7 external calls (McpServerStatusUpdated, new, ServerNotification, assert!, assert_eq!, start_embedded_app_server_for_picker, from).

async fn app_scoped_mcp_startup_notifications_do_not_render_in_active_thread()

Purpose: Ensures app-wide MCP startup notifications do not appear as active-thread transcript messages.

Data flow: An MCP status notification without a thread id is handled, and no history or active transcript output appears.

Call relations: It covers the app-scoped branch of MCP startup handling.

Call graph: calls 2 internal fn (new, make_test_app_with_channels); 5 external calls (McpServerStatusUpdated, ServerNotification, assert!, assert_eq!, start_embedded_app_server_for_picker).

async fn active_side_thread_renders_live_mcp_startup_notifications()

Purpose: Verifies an active side thread does render its own live MCP startup notifications.

Data flow: A side thread is activated, MCP starting and failed notifications for that side thread are handled, queued events are processed, and warning text is rendered once.

Call relations: It pairs with the primary-thread ignore test to prove thread-specific routing works.

Call graph: calls 5 internal fn (new, new, lines_to_single_string, make_test_app_with_channels, test_thread_session); 8 external calls (McpServerStatusUpdated, new, ServerNotification, assert!, assert_eq!, start_embedded_app_server_for_picker, matches!, from).

async fn side_restore_user_message_puts_inline_question_back_in_composer()

Purpose: Checks that restoring a side user message places its text back in the composer.

Data flow: A user message goes into the restore function, and the composer text becomes that message.

Call relations: It directly tests side-conversation prompt restoration.

Call graph: calls 2 internal fn (make_test_app, from); 1 external calls (assert_eq!).

async fn side_discard_selection_keeps_current_side_thread()

Purpose: Checks which side thread should be discarded when switching selections.

Data flow: With a side thread active, selecting that same thread returns no discard target, while selecting the parent returns the side thread id.

Call relations: It tests the selection guard used around side-thread switching.

Call graph: calls 3 internal fn (new, new, make_test_app); 1 external calls (assert_eq!).

async fn discard_side_thread_removes_agent_navigation_entry() -> Result<()>

Purpose: Verifies discarding a live side thread removes its side state and agent navigation entry.

Data flow: An ephemeral server thread is started and registered as side state, discard succeeds, and local navigation/state entries disappear.

Call relations: It uses the embedded app server to test the successful discard path.

Call graph: calls 3 internal fn (new, new, make_test_app); 4 external calls (pin, assert!, assert_eq!, start_embedded_app_server_for_picker).

async fn discard_side_thread_keeps_local_state_when_server_close_fails() -> Result<()>

Purpose: Ensures local side-thread state is kept if the server cannot close that thread.

Data flow: A fake side thread is registered without a real server thread, discard fails, and active id, side state, and navigation remain.

Call relations: It tests the failure branch of side discard.

Call graph: calls 3 internal fn (new, new, make_test_app); 4 external calls (pin, assert!, assert_eq!, start_embedded_app_server_for_picker).

async fn discard_closed_side_thread_removes_local_state_without_server_rpc()

Purpose: Checks that already-closed side threads can be removed locally without a server call.

Data flow: Local side state, channel, and navigation are seeded; discard-closed runs and removes all local records.

Call relations: It covers cleanup for replay-only or closed side threads.

Call graph: calls 4 internal fn (new, new, make_test_app, new); 2 external calls (assert!, assert_eq!).

async fn active_non_primary_shutdown_target_returns_none_for_non_shutdown_event() -> Result<()>

Purpose: Checks that non-shutdown notifications do not trigger a switch back to the primary thread.

Data flow: Active and primary thread ids are set differently, a non-shutdown notification is inspected, and no target is returned.

Call relations: It tests the shutdown-target helper’s filtering.

Call graph: calls 2 internal fn (new, make_test_app); 1 external calls (assert_eq!).

async fn active_non_primary_shutdown_target_returns_none_for_primary_thread_shutdown() -> Result<()>

Purpose: Checks that shutting down the primary active thread does not produce a non-primary switch target.

Data flow: The active and primary ids are the same, a thread-closed notification is inspected, and no target is returned.

Call relations: It covers the primary-thread branch of shutdown-target logic.

Call graph: calls 2 internal fn (new, make_test_app); 1 external calls (assert_eq!).

async fn active_non_primary_shutdown_target_returns_ids_for_non_primary_shutdown() -> Result<()>

Purpose: Verifies that closing an active non-primary thread returns both the closing thread and primary thread ids.

Data flow: Different active and primary ids are set, the active thread close notification is inspected, and the expected pair is returned.

Call relations: It tests the normal switch-back case after a side or agent thread closes.

Call graph: calls 2 internal fn (new, make_test_app); 1 external calls (assert_eq!).

async fn active_non_primary_shutdown_target_returns_none_when_shutdown_exit_is_pending() -> Result<()>

Purpose: Ensures pending shutdown-exit suppresses automatic switching for that same thread.

Data flow: A pending shutdown exit id is set to the active thread, the close notification is inspected, and no target is returned.

Call relations: It protects explicit exit handling from being interrupted by thread-switch behavior.

Call graph: calls 2 internal fn (new, make_test_app); 1 external calls (assert_eq!).

async fn active_non_primary_shutdown_target_still_switches_for_other_pending_exit_thread() -> Result<()>

Purpose: Checks that a pending shutdown for some other thread does not suppress switching for the active thread.

Data flow: The pending shutdown id differs from the active id, the active close notification is inspected, and the switch target is returned.

Call relations: It completes the shutdown-target edge cases.

Call graph: calls 2 internal fn (new, make_test_app); 1 external calls (assert_eq!).

async fn render_clear_ui_header_after_long_transcript_for_snapshot() -> String

Purpose: Builds a long fake transcript and renders the fresh header shown after clearing the UI.

Data flow: A test app with long user and agent cells is created, clear-header lines are rendered to text, and assertions ensure old notices and transcript text are absent.

Call relations: Two snapshot tests call this helper so both clear paths compare against the same expected header.

Call graph: calls 1 internal fn (make_test_app); called by 2 (clear_ui_after_long_transcript_snapshots_fresh_header_only, ctrl_l_clear_ui_after_long_transcript_reuses_clear_header_snapshot); 2 external calls (assert!, vec!).

async fn clear_ui_after_long_transcript_snapshots_fresh_header_only()

Purpose: Snapshots the header shown after clearing a long transcript.

Data flow: The shared clear-header renderer produces text, and the snapshot assertion compares it to the saved output.

Call relations: It depends on render_clear_ui_header_after_long_transcript_for_snapshot for setup.

Call graph: calls 1 internal fn (render_clear_ui_header_after_long_transcript_for_snapshot); 1 external calls (assert_app_snapshot!).

async fn ctrl_l_clear_ui_after_long_transcript_reuses_clear_header_snapshot()

Purpose: Ensures the Ctrl+L clear path uses the same fresh-header rendering as the general clear path.

Data flow: The shared renderer produces text and the same snapshot name is checked.

Call relations: It reuses the clear-header helper to keep both user actions aligned.

Call graph: calls 1 internal fn (render_clear_ui_header_after_long_transcript_for_snapshot); 1 external calls (assert_app_snapshot!).

async fn clear_ui_header_shows_fast_status_for_fast_capable_models()

Purpose: Checks that the clear header shows fast-mode status when the selected model and account support it.

Data flow: A model, effort, service tier, auth state, and model catalog are configured, then header text is snapshot-tested.

Call relations: It uses chat-widget test helpers for fast-mode catalog and authentication state.

Call graph: calls 1 internal fn (make_test_app); 3 external calls (assert_app_snapshot!, set_chatgpt_auth, set_fast_mode_test_catalog).

async fn make_test_app() -> App

Purpose: Creates a fully usable test App with dummy chat widget, config, file search, telemetry, and empty runtime state.

Data flow: No input is needed; it builds supporting objects and returns an App with default test-safe fields.

Call relations: Most tests call this when they do not need to inspect app-event or operation channels.

Call graph: calls 8 internal fn (default, without_managed_config_for_tests, default_for_tests, new, get_model_offline_for_tests, test_session_telemetry, new, defaults); called by 64 (active_non_primary_shutdown_target_returns_ids_for_non_primary_shutdown, active_non_primary_shutdown_target_returns_none_for_non_shutdown_event, active_non_primary_shutdown_target_returns_none_for_primary_thread_shutdown, active_non_primary_shutdown_target_returns_none_when_shutdown_exit_is_pending, active_non_primary_shutdown_target_still_switches_for_other_pending_exit_thread, active_turn_id_for_thread_uses_snapshot_turns, attach_live_thread_for_selection_rejects_empty_non_ephemeral_fallback_threads, attach_live_thread_for_selection_rejects_unmaterialized_fallback_threads, backtrack_esc_does_not_steal_empty_vim_insert_escape, clear_only_ui_reset_allows_active_skill_warning_to_render_again (+15 more)); 13 external calls (new, new, new, new, new, default, make_chatwidget_manual_with_sender, default, default, default (+3 more)).

async fn make_test_app_with_channels() -> (
    App,
    tokio::sync::mpsc::UnboundedReceiver<AppEvent>,
    tokio::sync::mpsc::UnboundedReceiver<Op>,
)

Purpose: Creates a test App and also returns receivers for app events and outgoing operations.

Data flow: It builds the same app as make_test_app, but keeps the event and operation receivers so tests can inspect what the app emits.

Call relations: Tests that need to assert submitted operations or inserted history cells use this helper.

Call graph: calls 8 internal fn (default, without_managed_config_for_tests, default_for_tests, new, get_model_offline_for_tests, test_session_telemetry, new, defaults); called by 52 (active_side_thread_renders_live_mcp_startup_notifications, app_scoped_mcp_startup_notifications_do_not_render_in_active_thread, apply_permission_profile_selection_preserves_loader_overrides, backtrack_remote_image_only_selection_clears_existing_composer_draft, backtrack_resubmit_preserves_data_image_urls_in_user_turn, backtrack_selection_with_duplicate_history_targets_unique_turn, cancelled_turn_edit_restores_prompt_and_rolls_back_latest_turn, capped_resize_reflow_renders_recent_suffix_only, enqueue_primary_thread_session_replays_buffered_approval_after_attach, enqueue_primary_thread_session_replays_turns_before_initial_prompt_submit (+15 more)); 13 external calls (new, new, new, new, new, default, make_chatwidget_manual_with_sender, default, default, default (+3 more)).

async fn set_thread_goal_draft_materializes_long_objective_and_confirms_before_paste() -> Result<()>

Purpose: Tests the thread-goal editor for long objectives, pasted text, stale paste placeholders, whitespace paste, and image attachments.

Data flow: A live thread is started, several goal drafts are applied, and server goal state plus attachment files are checked after each case.

Call relations: It exercises goal-file helpers through the app-server-backed set_thread_goal_draft flow.

Call graph: calls 2 internal fn (from_app_server, make_test_app); 9 external calls (default, assert!, assert_eq!, start_embedded_app_server_for_picker, format!, read_dir, write, tempdir, vec!).

async fn replace_goal_confirmation_snapshot()

Purpose: Snapshots the confirmation popup shown when replacing an existing thread goal.

Data flow: The confirmation UI is shown with a new goal draft, the bottom popup is rendered, and the snapshot is checked.

Call relations: It validates the visible prompt produced before goal replacement.

Call graph: calls 2 internal fn (new, make_test_app); 2 external calls (default, assert_app_snapshot!).

fn test_thread_session(thread_id: ThreadId, cwd: PathBuf) -> ThreadSessionState

Purpose: Builds a standard fake thread session for tests.

Data flow: A thread id and working directory go in; a session state with default model, permissions, and metadata comes out.

Call relations: Many replay, picker, side-thread, and feedback tests use this to avoid repeating session setup.

Call graph: calls 1 internal fn (read_only); called by 32 (active_side_thread_renders_live_mcp_startup_notifications, active_turn_id_for_thread_uses_snapshot_turns, enqueue_primary_thread_session_replays_buffered_approval_after_attach, enqueue_primary_thread_session_replays_turns_before_initial_prompt_submit, feedback_submission_for_inactive_thread_replays_into_origin_thread, inactive_thread_approval_badge_clears_after_turn_completion_notification, inactive_thread_approval_bubbles_into_active_view, inactive_thread_settings_notification_updates_cached_collaboration_mode, inactive_thread_started_notification_initializes_replay_session, inactive_thread_started_notification_preserves_primary_model_when_path_missing (+15 more)); 3 external calls (abs, new, new).

fn plain_line_cell(text: impl Into<String>) -> Arc<dyn HistoryCell>

Purpose: Creates a simple transcript history cell containing one line of plain text.

Data flow: Text goes in and a boxed history cell comes out.

Call relations: Resize reflow tests use it to build predictable transcripts.

Call graph: calls 1 internal fn (new); 2 external calls (new, vec!).

fn rendered_line_text(line: &crate::terminal_hyperlinks::HyperlinkLine) -> String

Purpose: Extracts plain text from a rendered terminal hyperlink line.

Data flow: A rendered line with spans goes in, span contents are joined, and a plain string comes out.

Call relations: Transcript reflow tests use it to compare rendered lines without styling details.

async fn capped_resize_reflow_renders_recent_suffix_only()

Purpose: Checks that resize reflow respects a row cap by rendering only the recent transcript tail.

Data flow: Twenty simple cells are rendered with a five-row limit, and only the expected last rows appear.

Call relations: It uses plain_line_cell and rendered_line_text to inspect reflow output.

Call graph: calls 1 internal fn (make_test_app_with_channels); 2 external calls (assert_eq!, Limit).

async fn uncapped_resize_reflow_renders_all_cells_when_row_cap_absent()

Purpose: Ensures disabling the resize row cap renders the full transcript.

Data flow: Twenty cells are rendered with the cap disabled, and the first and last rendered lines are checked.

Call relations: It covers the opposite branch of the capped reflow test.

Call graph: calls 1 internal fn (make_test_app_with_channels); 1 external calls (assert_eq!).

async fn resize_reflow_wraps_transcript_early_when_pet_is_enabled()

Purpose: Checks that enabling the terminal pet reduces available text width and causes earlier wrapping.

Data flow: A markdown cell is rendered before and after installing a test pet, and the pet version produces more wrapped lines.

Call relations: It tests the interaction between decorative pet UI and transcript reflow.

Call graph: calls 1 internal fn (make_test_app_with_channels); 3 external calls (assert!, Supported, vec!).

async fn uncapped_resize_reflow_renders_all_cells_under_row_limit()

Purpose: Verifies that when content fits under the row cap, all cells are rendered.

Data flow: Three simple cells are rendered with a large limit, and all expected lines appear.

Call relations: It covers the non-truncating case of capped reflow.

Call graph: calls 1 internal fn (make_test_app_with_channels); 2 external calls (assert_eq!, Limit).

async fn initial_replay_buffer_keeps_recent_rows_when_row_cap_present()

Purpose: Checks that the initial replay buffer keeps only the newest rows when a row cap exists.

Data flow: Five lines are buffered with a three-row limit, and only lines two through four remain.

Call relations: It directly tests the app’s replay-buffer trimming helper.

Call graph: calls 1 internal fn (make_test_app_with_channels); 4 external calls (assert_eq!, buffer_initial_history_replay_display_lines, Limit, vec!).

async fn thread_switch_replay_buffer_uses_transcript_tail_mode_when_row_cap_present()

Purpose: Ensures thread-switch replay uses transcript-tail mode when row capping is enabled.

Data flow: Thread-switch replay buffering starts with a three-row cap, and the buffer is marked to render from transcript tail.

Call relations: It tests setup behavior before replaying a switched thread.

Call graph: calls 1 internal fn (make_test_app_with_channels); 2 external calls (assert!, Limit).

async fn thread_switch_replay_buffer_is_disabled_without_row_cap()

Purpose: Checks that thread-switch replay buffering is not used when there is no row cap.

Data flow: Thread-switch replay buffering starts with the cap disabled, and no buffer is created.

Call relations: It pairs with the row-cap thread-switch buffer test.

Call graph: calls 1 internal fn (make_test_app_with_channels); 1 external calls (assert!).

async fn height_shrink_schedules_resize_reflow()

Purpose: Verifies that shrinking terminal height schedules transcript reflow.

Data flow: The app sees an unchanged draw size first, then a shorter one, and the second call marks reflow pending.

Call relations: It tests draw-size change handling with a dummy frame requester.

Call graph: calls 2 internal fn (make_test_app_with_channels, test_dummy); 1 external calls (assert!).

fn test_turn(turn_id: &str, status: TurnStatus, items: Vec<ThreadItem>) -> Turn

Purpose: Builds a fake app-server turn for tests.

Data flow: A turn id, status, and items go in; a turn object with default timing and error fields comes out.

Call relations: Turn notification helpers and side snapshot tests use this to create consistent turn data.

Call graph: called by 3 (side_thread_snapshot_hides_forked_parent_transcript, turn_completed_notification, turn_started_notification).

fn turn_started_notification(thread_id: ThreadId, turn_id: &str) -> ServerNotification

Purpose: Creates a fake server notification saying a turn started.

Data flow: A thread id and turn id go in; a notification containing an in-progress turn comes out.

Call relations: Replay, picker, and side-parent lifecycle tests use it to simulate live server progress.

Call graph: calls 1 internal fn (test_turn); called by 9 (open_agent_picker_clears_completed_path_backed_agent_running_state, open_agent_picker_refreshes_replay_only_path_backed_liveness, replay_only_thread_keeps_restored_queue_visible, replay_thread_snapshot_does_not_submit_queue_before_replay_catches_up, replay_thread_snapshot_in_progress_turn_restores_running_queue_state, replay_thread_snapshot_keeps_queue_when_running_state_only_comes_from_snapshot, replayed_interrupted_turn_restores_queued_input_to_composer, replayed_turn_complete_submits_restored_queued_follow_up, side_parent_status_tracks_parent_turn_lifecycle); 3 external calls (TurnStarted, new, to_string).

fn turn_completed_notification(
    thread_id: ThreadId,
    turn_id: &str,
    status: TurnStatus,
) -> ServerNotification

Purpose: Creates a fake server notification saying a turn completed with a given status.

Data flow: A thread id, turn id, and final status go in; a completion notification with timing fields comes out.

Call relations: Queue replay, picker liveness, approval badge, and side lifecycle tests use it.

Call graph: calls 1 internal fn (test_turn); called by 4 (inactive_thread_approval_badge_clears_after_turn_completion_notification, open_agent_picker_clears_completed_path_backed_agent_running_state, replay_thread_snapshot_does_not_submit_queue_before_replay_catches_up, side_parent_status_tracks_parent_turn_lifecycle); 3 external calls (TurnCompleted, new, to_string).

fn thread_closed_notification(thread_id: ThreadId) -> ServerNotification

Purpose: Creates a fake server notification that a thread closed.

Data flow: A thread id goes in and a thread-closed notification comes out.

Call relations: Channel and shutdown-target tests use it to simulate thread shutdown.

Call graph: called by 1 (enqueue_thread_event_does_not_block_when_channel_full); 2 external calls (ThreadClosed, to_string).

fn token_usage_notification(
    thread_id: ThreadId,
    turn_id: &str,
    model_context_window: Option<i64>,
) -> ServerNotification

Purpose: Creates a fake token-usage update notification.

Data flow: A thread id, turn id, and optional context-window size go in; a notification with token counts comes out.

Call relations: The status-line token usage test uses it to drive thread event handling.

Call graph: called by 1 (token_usage_update_refreshes_status_line_with_runtime_context_window); 2 external calls (ThreadTokenUsageUpdated, to_string).

fn agent_message_delta_notification(
    thread_id: ThreadId,
    turn_id: &str,
    item_id: &str,
    delta: &str,
) -> ServerNotification

Purpose: Creates a fake streaming agent-message update.

Data flow: A thread id, turn id, item id, and text delta go in; an agent-message delta notification comes out.

Call relations: Queue replay tests use it to make the chat widget think a turn is actively streaming.

Call graph: called by 6 (replay_only_thread_keeps_restored_queue_visible, replay_thread_snapshot_does_not_submit_queue_before_replay_catches_up, replay_thread_snapshot_in_progress_turn_restores_running_queue_state, replay_thread_snapshot_keeps_queue_when_running_state_only_comes_from_snapshot, replayed_interrupted_turn_restores_queued_input_to_composer, replayed_turn_complete_submits_restored_queued_follow_up); 2 external calls (AgentMessageDelta, to_string).

fn exec_approval_request(
    thread_id: ThreadId,
    turn_id: &str,
    item_id: &str,
    approval_id: Option<&str>,
) -> ServerRequest

Purpose: Builds a standard fake command-execution approval request.

Data flow: Thread, turn, item, and optional approval ids go in; a server request asking approval for echo hello comes out.

Call relations: Approval buffering, inactive approval, side status, and badge tests reuse this helper.

Call graph: called by 10 (enqueue_primary_thread_session_replays_buffered_approval_after_attach, inactive_thread_approval_badge_clears_after_turn_completion_notification, inactive_thread_approval_bubbles_into_active_view, inactive_thread_exec_approval_preserves_context, inactive_thread_exec_approval_splits_shell_wrapped_command, refresh_pending_thread_approvals_only_lists_inactive_threads, resolved_buffered_approval_does_not_become_actionable_after_drain, side_defers_parent_approval_overlay_until_parent_replay, side_defers_subagent_approval_overlay_until_side_exits, side_parent_status_prioritizes_input_over_approval); 2 external calls (Integer, to_string).

fn request_user_input_request(thread_id: ThreadId, turn_id: &str, item_id: &str) -> ServerRequest

Purpose: Builds a fake request asking the user for tool input.

Data flow: Thread, turn, and item ids go in; a tool-input server request comes out.

Call relations: The side-parent priority test uses it to compare input requests against approval requests.

Call graph: called by 1 (side_parent_status_prioritizes_input_over_approval); 3 external calls (Integer, new, to_string).

async fn feedback_submission_without_thread_emits_error_history_cell()

Purpose: Checks that a feedback upload failure with no origin thread shows an error history cell.

Data flow: The app handles a failed feedback result, and the emitted history cell text is compared.

Call relations: It tests feedback result display through the app event channel.

Call graph: calls 1 internal fn (make_test_app_with_channels); 2 external calls (assert_eq!, panic!).

async fn feedback_submission_for_inactive_thread_replays_into_origin_thread()

Purpose: Ensures feedback results for an inactive thread are stored with that thread and appear when it is replayed.

Data flow: Origin and active threads are set up, feedback success is handled for the origin, no active UI event appears, then replaying origin shows the upload link.

Call relations: It tests thread-local feedback event buffering and replay.

Call graph: calls 5 internal fn (new, lines_to_single_string, make_test_app_with_channels, test_thread_session, new_with_session); 3 external calls (new, assert!, assert_matches!).

fn next_user_turn_op(op_rx: &mut tokio::sync::mpsc::UnboundedReceiver<Op>) -> Op

Purpose: Pulls the next user-turn operation from an operation receiver, ignoring unrelated operations.

Data flow: An operation receiver goes in; it drains available operations until it finds a user turn, returns it, or panics with what it saw.

Call relations: Queue and draft replay tests use this helper after simulating a submit.

Call graph: called by 4 (replay_thread_snapshot_does_not_submit_queue_before_replay_catches_up, replay_thread_snapshot_restores_collaboration_mode_for_draft_submit, replay_thread_snapshot_restores_pending_pastes_for_submit, replayed_turn_complete_submits_restored_queued_follow_up); 5 external calls (try_recv, new, format!, matches!, panic!).

fn lines_to_single_string(lines: &[Line<'_>]) -> String

Purpose: Turns rendered UI lines into plain text for assertions.

Data flow: A slice of styled lines goes in; span text is joined line by line into one newline-separated string.

Call relations: Many snapshot and rendering tests use it to ignore styling while checking visible text.

Call graph: called by 9 (active_side_thread_renders_live_mcp_startup_notifications, bypass_hook_trust_startup_warning_snapshot, enqueue_primary_thread_session_replays_turns_before_initial_prompt_submit, feedback_submission_for_inactive_thread_replays_into_origin_thread, inactive_thread_file_change_approval_recovers_buffered_changes, primary_thread_ignores_child_mcp_startup_notifications, replace_chat_widget_reseeds_collab_agent_metadata_for_replay, replay_snapshot_with_pending_request_suppresses_replay_notices, side_thread_snapshot_skips_session_header_preamble); 1 external calls (iter).

fn test_session_telemetry(config: &Config, model: &str) -> SessionTelemetry

Purpose: Creates fake telemetry metadata for a test session.

Data flow: A config and model name go in; offline model info is looked up and a session telemetry object comes out.

Call relations: make_test_app and make_test_app_with_channels use it while building test apps.

Call graph: calls 4 internal fn (construct_model_info_offline_for_tests, new, new, session_source_cli); called by 2 (make_test_app, make_test_app_with_channels); 1 external calls (to_models_manager_config).

fn active_turn_not_steerable_turn_error_extracts_structured_server_error()

Purpose: Checks that a structured server error for a non-steerable active turn can be extracted.

Data flow: A JSON-RPC error containing serialized turn-error data is built, and the extractor returns the original turn error.

Call relations: It tests error parsing used when steering an active turn fails.

Call graph: 2 external calls (assert_eq!, to_value).

fn session_start_error_surfaces_archived_guidance_without_rollout_path()

Purpose: Verifies archived-session startup errors show clear unarchive guidance without leaking rollout-path details.

Data flow: Fake resume and fork errors are wrapped, passed through session_start_error, and compared with the expected user-facing message.

Call relations: It tests startup error cleanup for archived sessions.

Call graph: calls 1 internal fn (from_string); 4 external calls (assert_eq!, eyre!, format!, from).

fn active_turn_steer_race_detects_missing_active_turn()

Purpose: Checks that a steer request failing because there is no active turn is recognized as a race.

Data flow: A JSON-RPC error with the missing-active-turn message is parsed and returns the missing-race marker.

Call relations: It tests one branch of active-turn race detection.

Call graph: 1 external calls (assert_eq!).

fn active_turn_steer_race_extracts_actual_turn_id_from_mismatch()

Purpose: Checks that a steer race error extracts the actual active turn id from the server message.

Data flow: A mismatch error string is parsed, and the actual turn id is returned in the race result.

Call relations: It covers the mismatch branch of steer race detection.

Call graph: 1 external calls (assert_eq!).

fn active_turn_interrupt_race_extracts_actual_turn_id_from_mismatch()

Purpose: Checks that an interrupt race error extracts the actual active turn id.

Data flow: A mismatch error string from turn interrupt is parsed and returns the actual turn id.

Call relations: It tests the interrupt-specific race parser.

Call graph: 1 external calls (assert_eq!).

async fn fresh_session_config_uses_current_service_tier()

Purpose: Ensures new session configs use the chat widget’s current service tier.

Data flow: The widget is set to Fast service tier, fresh session config is built, and the tier is present.

Call relations: It tests session-start config generation from runtime UI state.

Call graph: calls 1 internal fn (make_test_app); 1 external calls (assert_eq!).

async fn backtrack_selection_with_duplicate_history_targets_unique_turn()

Purpose: Checks that backtrack selection targets the correct user turn even when history contains duplicated earlier turns.

Data flow: A transcript with duplicate sections and an edited later prompt is built, selection is confirmed, rollback is applied, and rollback count plus restored attachments are checked.

Call relations: It exercises backtrack selection, composer restoration, and rollback operation emission.

Call graph: calls 4 internal fn (read_only, new, make_test_app_with_channels, user_count); 5 external calls (new, new, assert_eq!, format!, vec!).

async fn backtrack_remote_image_only_selection_clears_existing_composer_draft()

Purpose: Ensures backtracking to a message with only a remote image clears stale composer text.

Data flow: A stale draft is set, a remote-image-only backtrack selection is applied, and the composer is empty while the image remains.

Call relations: It tests a backtrack edge case around image-only prompts.

Call graph: calls 1 internal fn (make_test_app_with_channels); 4 external calls (new, new, assert_eq!, vec!).

async fn cancelled_turn_edit_restores_prompt_and_rolls_back_latest_turn()

Purpose: Checks that canceling a turn edit restores the prompt and rolls back the latest turn.

Data flow: A prompt with a remote image is applied as a cancelled edit, composer and images are restored, and a one-turn rollback operation is emitted.

Call relations: It tests cancelled edit recovery for non-empty local history.

Call graph: calls 1 internal fn (make_test_app_with_channels); 5 external calls (new, assert_eq!, assert_matches!, assert_snapshot!, vec!).

async fn first_cancelled_turn_edit_restores_prompt_without_local_history()

Purpose: Ensures cancelling the first turn edit works even when there is no transcript history.

Data flow: A prompt is restored into an empty-history app and a one-turn rollback operation is emitted.

Call relations: It covers the first-turn branch of cancelled edit recovery.

Call graph: calls 1 internal fn (make_test_app_with_channels); 4 external calls (new, assert_eq!, assert_matches!, vec!).

async fn backtrack_resubmit_preserves_data_image_urls_in_user_turn()

Purpose: Verifies that resubmitting after backtrack preserves inline data-image URLs.

Data flow: A transcript user message with a data URL is backtracked, Enter submits it, and the outgoing user turn includes the image URL.

Call relations: It links backtrack restoration to normal chat-widget submission.

Call graph: calls 3 internal fn (read_only, new, make_test_app_with_channels); 5 external calls (new, new, new, assert!, vec!).

async fn replay_thread_snapshot_replays_turn_history_in_order()

Purpose: Checks that replaying stored turns inserts user messages in their original order.

Data flow: A snapshot with two completed turns is replayed, emitted history cells are collected, and user messages match the expected sequence.

Call relations: It tests snapshot turn replay using the shared session helper.

Call graph: calls 3 internal fn (new, make_test_app_with_channels, test_thread_session); 3 external calls (new, assert_eq!, vec!).

async fn replace_chat_widget_reseeds_collab_agent_metadata_for_replay()

Purpose: Ensures replacing the chat widget keeps collaboration agent names available during replay.

Data flow: Agent navigation metadata is seeded, a replacement widget is installed, a collab wait item is replayed, and rendered text still contains the agent label.

Call relations: It tests replace_chat_widget together with later snapshot replay.

Call graph: calls 4 internal fn (from_string, lines_to_single_string, make_test_app_with_channels, test_dummy); 4 external calls (new, assert!, new_with_app_event, vec!).

async fn refreshed_snapshot_session_persists_resumed_turns()

Purpose: Checks that refreshing a snapshot with resumed server data updates both the snapshot and cached store.

Data flow: A cached session is replaced with a refreshed session and turns, and both the in-memory snapshot and store contain the new data.

Call relations: It tests the snapshot refresh path used before replaying resumed threads.

Call graph: calls 4 internal fn (new, make_test_app, test_thread_session, new_with_session); 3 external calls (new, assert_eq!, vec!).

async fn queued_rollback_syncs_overlay_and_clears_deferred_history()

Purpose: Verifies a rollback on a non-pending thread updates transcript, overlay, deferred lines, and pending UI state together.

Data flow: A transcript, overlay, deferred line, and pending usage cell are seeded; rollback removes the latest turn and clears stale UI pieces.

Call relations: It exercises backtrack rollback cleanup across several app UI fields.

Call graph: calls 2 internal fn (make_test_app, new_transcript); 6 external calls (new, new, assert!, assert_eq!, panic!, vec!).

async fn late_usage_result_can_follow_finalized_plan()

Purpose: Checks that a late token-activity result can still be accepted after a streamed plan was finalized.

Data flow: A token activity refresh starts, a plan stream is consolidated, then the token result finishes and is available for insertion.

Call relations: It tests ordering between usage refresh output and plan stream consolidation.

Call graph: calls 1 internal fn (make_test_app_with_channels); 5 external calls (new, assert!, new_proposed_plan_stream, panic!, vec!).

async fn thread_rollback_response_discards_queued_active_thread_events()

Purpose: Ensures stale active-thread events queued before a rollback response are discarded.

Data flow: A warning event is queued in the active receiver, rollback response is handled, and the receiver is empty afterward.

Call relations: It protects rollback replay from being polluted by old channel events.

Call graph: calls 2 internal fn (new, make_test_app); 6 external calls (ConfigWarning, new, new, assert!, channel, Notification).

async fn new_session_requests_shutdown_for_previous_conversation()

Purpose: Checks that shutting down the current conversation through the app server does not submit the old local shutdown operation.

Data flow: A thread session is installed, channels are drained, shutdown is requested, and no Op::Shutdown appears.

Call relations: It tests the new app-server shutdown path for starting a new session.

Call graph: calls 3 internal fn (read_only, new, make_test_app_with_channels); 5 external calls (pin, new, new, assert!, start_embedded_app_server_for_picker).

async fn shutdown_first_exit_returns_immediate_exit_when_shutdown_submit_fails()

Purpose: Ensures shutdown-first exit falls back to immediate exit if shutdown submission cannot proceed.

Data flow: An active thread id is set without a real server thread, exit handling runs, and it returns user-requested exit with no pending shutdown id.

Call relations: It tests failure handling in exit-mode orchestration.

Call graph: calls 2 internal fn (new, make_test_app); 4 external calls (pin, assert!, assert_eq!, start_embedded_app_server_for_picker).

async fn shutdown_first_exit_uses_app_server_shutdown_without_submitting_op()

Purpose: Verifies shutdown-first exit uses the app server and does not emit a local shutdown operation.

Data flow: Exit handling runs with an active thread, returns immediate exit in the test setup, and the operation channel stays empty.

Call relations: It complements the shutdown submission failure test with channel inspection.

Call graph: calls 2 internal fn (new, make_test_app_with_channels); 4 external calls (pin, assert!, assert_eq!, start_embedded_app_server_for_picker).

async fn interrupt_without_active_turn_is_treated_as_handled()

Purpose: Checks that interrupting when no turn is active is considered successfully handled.

Data flow: A real thread is started, an interrupt operation is submitted through the app server, and the result is handled.

Call relations: It tests app-server operation submission for a harmless interrupt race.

Call graph: calls 1 internal fn (make_test_app); 4 external calls (pin, assert_eq!, interrupt, start_embedded_app_server_for_picker).

async fn override_turn_context_sends_thread_settings_update()

Purpose: Verifies a turn-context override sends a thread settings update to the server and later updates cached session state from the notification.

Data flow: A thread starts, an override operation with permissions, model, service tier, collaboration mode, and personality is submitted, the server notification is checked, then handled by the app.

Call relations: It uses next_thread_settings_updated to wait for the app-server notification.

Call graph: calls 3 internal fn (new, make_test_app, next_thread_settings_updated); 6 external calls (pin, ThreadSettingsUpdated, ServerNotification, assert_eq!, override_turn_context, start_embedded_app_server_for_picker).

async fn thread_setting_update_params_sync_model_and_default_reasoning()

Purpose: Checks that model and reasoning-effort changes produce thread-settings update parameters that also sync collaboration mode.

Data flow: The active thread and widget settings are changed, update params are requested, and model, effort, and collaboration settings are inspected.

Call relations: It directly tests parameter creation for active-thread settings updates.

Call graph: calls 2 internal fn (new, make_test_app); 1 external calls (assert_eq!).

async fn inactive_thread_settings_notification_updates_cached_collaboration_mode()

Purpose: Ensures settings notifications for inactive threads update cached collaboration mode and personality without overwriting the session model.

Data flow: An inactive thread session is cached, a settings update notification is queued, cached state is inspected, then applied to the widget and checked.

Call relations: It tests inactive-thread settings caching and later widget restoration.

Call graph: calls 6 internal fn (read_only, new, make_test_app, test_absolute_path, test_thread_session, new_with_session); 3 external calls (ThreadSettingsUpdated, new, assert_eq!).

async fn clear_only_ui_reset_preserves_chat_session_state()

Purpose: Checks that clearing only the UI removes transcript and overlays but keeps the active chat session and draft.

Data flow: Session, draft, transcript, overlay, deferred lines, and backtrack state are seeded; reset runs and only UI display state is cleared.

Call relations: It protects Ctrl+L-style clearing from losing conversation state.

Call graph: calls 5 internal fn (read_only, new, make_test_app, defaults, new_transcript); 5 external calls (new, new, assert!, assert_eq!, vec!).

async fn clear_only_ui_reset_allows_active_skill_warning_to_render_again()

Purpose: Ensures clearing the UI also resets remembered skill warnings so active errors can be shown again.

Data flow: A skill error is recorded once, suppressed the second time, UI reset runs, and the same error is considered new again.

Call relations: It tests clear-state interaction with skill warning deduplication.

Call graph: calls 1 internal fn (make_test_app); 1 external calls (assert_eq!).

async fn backtrack_esc_does_not_steal_empty_vim_insert_escape()

Purpose: Checks that backtrack Escape handling does not interfere with Vim insert-mode Escape.

Data flow: The test toggles Vim mode, enters insert mode, checks Escape handling priority, sends Escape, and verifies backtrack remains unprimed.

Call relations: It tests keyboard dispatch between backtrack and Vim editing modes.

Call graph: calls 1 internal fn (make_test_app); 3 external calls (assert!, Char, new).

async fn side_conversations_reject_backtrack_esc_without_stealing_vim_insert_escape()

Purpose: Ensures side conversations reject backtrack Escape, but still let Vim insert-mode Escape work.

Data flow: Side mode is activated, Escape handling decisions are checked before and after entering Vim insert mode.

Call relations: It tests keyboard priority for side conversations.

Call graph: calls 1 internal fn (make_test_app); 3 external calls (assert!, Char, new).

async fn side_backtrack_rejection_reports_unavailable_message_snapshot()

Purpose: Snapshots the message shown when backtrack is rejected in a side conversation.

Data flow: Backtrack is marked primed, rejection runs, the emitted history cell is rendered, and the snapshot is checked.

Call relations: It tests the user-facing feedback path for side backtrack rejection.

Call graph: calls 1 internal fn (make_test_app_with_channels); 3 external calls (assert!, assert_app_snapshot!, panic!).

async fn start_config_write_test_app_server(app: &App) -> Result<AppServerSession>

Purpose: Starts an embedded app server for tests that need to write configuration.

Data flow: A test app goes in; an app-server session configured from the app’s config comes out.

Call relations: Guardian feature-flag tests call this helper before exercising config writes.

Call graph: called by 4 (update_feature_flags_disabling_guardian_clears_manual_review_policy_without_history, update_feature_flags_disabling_guardian_clears_review_policy_and_restores_default, update_feature_flags_enabling_guardian_overrides_explicit_manual_review_policy, update_feature_flags_enabling_guardian_selects_auto_review); 2 external calls (pin, start_embedded_app_server_for_picker).

fn all_model_presets() -> Vec<ModelPreset>

Purpose: Provides a fresh copy of the shared test model list. Tests use it as their starting point so they can safely edit model visibility, upgrade data, or tooltip data without changing the original fixture.

Data flow: It reads the project’s test model preset fixture, clones it, and returns the clone. The result is a list of model presets that each test can freely modify.

Call relations: This helper is called by most of the tests that need a realistic model catalog. It acts like a clean sample shelf of models that each test can rearrange before asking the production selection or migration logic what it would do.

Call graph: called by 7 (model_migration_prompt_shows_for_hidden_model, model_migration_prompt_skips_when_target_missing_or_hidden, prepare_startup_tooltip_override_persists_model_availability_nux_count, select_model_availability_nux_picks_only_eligible_model, select_model_availability_nux_returns_none_when_all_models_are_exhausted, select_model_availability_nux_skips_missing_and_exhausted_models, select_model_availability_nux_uses_existing_model_order_as_priority).

fn model_availability_nux_config(shown_count: &[(&str, u32)]) -> ModelAvailabilityNuxConfig

Purpose: Builds a small configuration object that records how many times each model’s availability tooltip has already been shown. Tests use it to simulate a user who has or has not already seen certain messages.

Data flow: It receives pairs of model name and show count, turns the model names into owned strings, and collects them into the configuration map. It returns a ModelAvailabilityNuxConfig ready to pass into the tooltip selection code.

Call relations: The NUX selection tests call this helper when they need to control the app’s memory of past tooltip displays. The helper feeds that simulated memory into the code under test so the tests can check whether exhausted models are skipped.

Call graph: called by 4 (select_model_availability_nux_picks_only_eligible_model, select_model_availability_nux_returns_none_when_all_models_are_exhausted, select_model_availability_nux_skips_missing_and_exhausted_models, select_model_availability_nux_uses_existing_model_order_as_priority).

fn model_migration_copy_to_plain_text(copy: &crate::model_migration::ModelMigrationCopy) -> String

Purpose: Turns rich migration prompt copy into plain text so a snapshot test can compare it easily. This avoids testing visual formatting details while still checking the words the user would read.

Data flow: It receives a ModelMigrationCopy value. If that value already has markdown text, it returns that text. Otherwise it builds a string by joining the heading spans, adding blank space, then appending each content line’s spans. The output is one plain string representing the prompt.

Call relations: The hidden-model migration prompt test uses this helper just before taking a snapshot. Internally it creates a new string when markdown is not present, then hands the simplified text to the snapshot assertion.

Call graph: 1 external calls (new).

async fn model_migration_prompt_only_shows_for_deprecated_models()

Purpose: Checks that the app only offers a migration prompt when the current model is actually meant to move to a newer target. This prevents users from being nagged when they are already on the right model.

Data flow: The test starts with an empty record of already-seen migrations. It asks the migration decision function about older models pointing to a newer model, then asks about a model pointing to itself. The expected outcome is true for deprecated upgrade cases and false for the self-target case.

Call relations: This async test sets up minimal state and then calls the migration prompt decision logic directly. Its assertions tell the larger test suite whether the basic “should we show this prompt?” rule is still working.

Call graph: 2 external calls (new, assert!).

fn select_model_availability_nux_picks_only_eligible_model()

Purpose: Checks that the startup availability tooltip is selected when exactly one model has a NUX message. This confirms the app can find the one model that should announce itself.

Data flow: The test gets the full model preset list, clears all availability messages, adds one message to the gpt-5.4 preset, and gives the selector an empty show-count config. It expects the selector to return a tooltip override containing that model slug and message.

Call relations: It uses all_model_presets to get realistic input and model_availability_nux_config to say no messages have been shown yet. Then it calls the selection logic and compares the result with the expected tooltip.

Call graph: calls 2 internal fn (all_model_presets, model_availability_nux_config); 1 external calls (assert_eq!).

fn select_model_availability_nux_skips_missing_and_exhausted_models()

Purpose: Checks that a model whose tooltip has already been shown the maximum number of times is skipped in favor of another eligible model. This keeps users from seeing the same availability notice forever.

Data flow: The test clears all messages, gives two models availability messages, and marks one model as already shown up to the maximum count. It then asks the selector for a tooltip. The expected output is the other model’s message.

Call relations: It builds its test catalog with all_model_presets and builds the simulated show-count memory with model_availability_nux_config. The selected result is then compared against the tooltip for the still-eligible model.

Call graph: calls 2 internal fn (all_model_presets, model_availability_nux_config); 1 external calls (assert_eq!).

fn select_model_availability_nux_uses_existing_model_order_as_priority()

Purpose: Checks that when more than one model could show an availability tooltip, the app uses the existing model order as its priority. This makes prompt choice predictable instead of depending on incidental setup order inside the test.

Data flow: The test clears all messages, assigns messages to two models, and passes an empty show-count config. It expects the selector to choose the model that comes first according to the catalog’s built-in ordering, returning that model’s slug and message.

Call relations: It relies on all_model_presets for the catalog order and model_availability_nux_config for a clean display history. It then exercises the selector and verifies that priority follows the catalog order.

Call graph: calls 2 internal fn (all_model_presets, model_availability_nux_config); 1 external calls (assert_eq!).

fn select_model_availability_nux_returns_none_when_all_models_are_exhausted()

Purpose: Checks that no startup availability tooltip is shown when every available message has already reached its allowed display count. This protects the app from showing stale repeated announcements.

Data flow: The test creates a catalog with one model availability message and a config saying that model has already been shown the maximum number of times. It asks the selector for a tooltip and expects no result.

Call relations: It uses all_model_presets to create the model list and model_availability_nux_config to simulate an exhausted message. The selection logic should hand back nothing, which the test confirms.

Call graph: calls 2 internal fn (all_model_presets, model_availability_nux_config); 1 external calls (assert_eq!).

async fn prepare_startup_tooltip_override_persists_model_availability_nux_count()

Purpose: Checks the full startup tooltip preparation path, including saving the updated display count to configuration storage. This matters because the app must remember that it already showed a NUX message across restarts.

Data flow: The test creates a temporary Codex home folder, builds a config from it, prepares a catalog with one availability message, and runs the startup tooltip preparation function. It expects the tooltip text to be returned, the in-memory show count to become 1, and a freshly reloaded config from the same folder to also contain that count.

Call relations: This test uses all_model_presets for model data and the config builder for temporary real configuration storage. It exercises the higher-level startup helper rather than only the selector, then reloads configuration to prove the change was persisted.

Call graph: calls 1 internal fn (all_model_presets); 2 external calls (assert_eq!, default).

async fn accepted_model_migration_persists_target_default_reasoning_effort()

Purpose: Checks what happens after a user accepts a model migration. It verifies that the chosen target model and its default reasoning effort are stored and that the rest of the app is notified through events.

Data flow: The test creates a temporary config with an old model and a previous reasoning effort, then creates an unbounded channel, which is a message pipe with no fixed queue limit for this test. It applies an accepted migration from gpt-5.2 to gpt-5.4 with Medium reasoning effort. Afterward, the config should contain the new model and effort, and the receiving side of the channel should contain the expected acknowledgement, model update, effort update, and persistence events.

Call relations: This test creates an AppEventSender around the channel and passes it into the migration-acceptance function. The function under test changes the config and sends events; the test then reads those events back from the channel to confirm each handoff happened.

Call graph: calls 1 internal fn (new); 4 external calls (assert_eq!, assert_matches!, default, unbounded_channel).

async fn model_migration_prompt_respects_hide_flag_and_self_target()

Purpose: Checks that a migration prompt is not shown when the user has already hidden or acknowledged that migration, and also not shown when the source and target are the same model. This prevents repeated or pointless prompts.

Data flow: The test creates a map saying the migration from gpt-5.2 to gpt-5.4 has already been seen. It asks the prompt decision function about that same migration and about a model targeting itself. Both checks should return false.

Call relations: This test supplies the seen-migration record directly to the migration decision logic. Its assertions cover two early-stop cases that should block the larger migration prompt flow.

Call graph: 2 external calls (new, assert!).

async fn model_migration_prompt_skips_when_target_missing_or_hidden()

Purpose: Checks that the app does not show a migration prompt when the upgrade target cannot actually be selected. This avoids inviting the user to move to a model that is missing from the catalog or hidden from the picker.

Data flow: First, the test edits a current model so its upgrade points to a missing target, then verifies that the prompt decision is false and that no target preset can be found. Next, it hides the normal target model from the picker and again verifies that the prompt is blocked and the target lookup returns none.

Call relations: It starts from all_model_presets, mutates the catalog into two bad states, and then calls the migration decision and target lookup logic. The test confirms those helpers agree that there is no valid target to offer.

Call graph: calls 1 internal fn (all_model_presets); 1 external calls (assert!).

async fn model_migration_prompt_shows_for_hidden_model()

Purpose: Checks a subtle case: the current old model may be hidden from the model picker, but the app should still be able to show its migration prompt if the upgrade target is visible. This lets users on an old hidden model move forward cleanly.

Data flow: The test creates a temporary config, gets the model presets, hides the current gpt-5.3-codex model, and ensures its upgrade target is visible. It verifies that the migration prompt is eligible, finds the target preset, builds the migration copy using the current and target model details, converts that copy to plain text, and compares it to a stored snapshot.

Call relations: It uses all_model_presets to create the catalog, calls the migration decision and target lookup logic, then passes the resulting model details into the copy-building logic. Finally, model_migration_copy_to_plain_text prepares the output for the snapshot assertion so wording changes are caught by the test suite.

Call graph: calls 1 internal fn (all_model_presets); 3 external calls (assert!, assert_snapshot!, default).

async fn session_summary_skips_when_no_usage_or_resume_hint()

Purpose: This test proves that the app does not show an empty session summary. If there are no tokens to report and no saved conversation to resume, the correct result is no summary at all.

Data flow: It starts with default token usage, meaning all counts are zero, and passes no thread ID, no thread name, and no rollout file path into session_summary. The function under test returns either a summary or nothing; the test expects nothing. If a summary appears, the assertion fails.

Call relations: During the test run, the test calls session_summary for the most minimal end-of-session case. It then uses an assertion to make sure the result is absent, confirming that later user-facing code would have nothing extra to display.

Call graph: 1 external calls (assert!).

async fn session_summary_skips_resume_hint_until_rollout_exists()

Purpose: This test checks that the app does not offer a resume command before the saved session file exists. That prevents the interface from giving users a command that cannot work yet.

Data flow: It creates zero token usage, builds a thread ID from a string, and chooses a rollout file path inside a temporary directory without actually creating the file. It passes those values into session_summary. Because the rollout file is missing, the expected output is still no summary.

Call relations: The test sets up a conversation that has an ID but has not been persisted to disk. It relies on thread ID parsing and default token usage setup, then asks session_summary what it would show. The final assertion confirms that no resume hint is handed back until the file system proves the session was saved.

Call graph: calls 1 internal fn (from_string); 2 external calls (assert!, default).

async fn session_summary_includes_resume_hint_for_persisted_rollout()

Purpose: This test proves that a saved session with token usage produces a useful summary. The summary should include both the token counts and a command the user can run to resume the conversation.

Data flow: It creates token usage with 10 input tokens, 2 output tokens, and 12 total tokens. It parses a thread ID, creates a temporary rollout file, writes a small line into that file, and calls session_summary with the usage, thread ID, and path. The result should be a summary whose usage line reports the counts and whose resume hint is codex resume followed by the thread ID.

Call relations: This test represents the normal successful shutdown path after a conversation has been saved. It writes the rollout file first so session_summary can safely produce a resume hint, then uses equality checks to verify the exact user-facing text that would be displayed.

Call graph: calls 1 internal fn (from_string); 3 external calls (default, assert_eq!, write).

async fn session_summary_names_picker_item_when_thread_has_name()

Purpose: This test checks the friendlier resume message used when a saved conversation has a name. Instead of only telling the user to resume by raw ID, the summary should mention the named picker item they can select.

Data flow: It creates nonzero token usage, parses a thread ID, creates and writes a temporary rollout file, and passes a thread name of my-session into session_summary. The returned summary should contain a resume hint that says to run codex resume and then select my-session, with the thread ID shown in parentheses.

Call relations: This test covers the path where the app has enough information to give a more human-friendly resume instruction. After setting up a persisted rollout, it calls session_summary and checks the exact hint text, making sure the named-session flow stays clear for users.

Call graph: calls 1 internal fn (from_string); 3 external calls (default, assert_eq!, write).

fn startup_waiting_gate_is_only_for_fresh_or_exit_session_selection()

Purpose: This test checks which startup choices make the app wait before processing the initial session. Starting fresh and exiting require the waiting gate, while resuming or forking an existing session should not.

Data flow: It creates several session-selection examples: fresh start, exit, resume, and fork. Each one is passed into the app’s startup-wait decision helper. The expected result is compared with the actual result, proving that only fresh or exit selections turn the wait flag on.

Call relations: This test exercises the small decision point that later startup code relies on before allowing thread events through. It does not drive the full app; it verifies the rule that other startup paths depend on.

Call graph: 1 external calls (assert_eq!).

fn startup_paused_goal_prompt_gate_is_only_for_quiet_resume()

Purpose: This test checks when the app should ask the user for a goal after resuming a paused session. It should only prompt during a plain resume with no initial text and no images attached.

Data flow: It builds resume and fork session targets, then tries combinations of optional startup text and optional image paths. The app’s prompt-decision helper receives those inputs and returns true or false. The test confirms that only a quiet resume, with no message and no images, asks for a paused goal.

Call relations: This protects the startup flow from showing an unnecessary prompt when the user has already supplied a request or when the action is not a normal resume. It checks the decision used before the chat view continues after startup.

Call graph: calls 1 internal fn (new); 6 external calls (from, new, assert!, Fork, Resume, vec!).

fn startup_waiting_gate_holds_active_thread_events_until_primary_thread_configured()

Purpose: This test verifies that, during a fresh start, active thread events are held back until the app knows its primary thread. This prevents events from being routed before the main conversation is ready.

Data flow: It starts with the wait flag turned on for a fresh session and asks whether active thread events should be handled. The answer is false. It then checks that the app should not stop waiting when there is no primary thread, but should stop when a primary thread id appears. After the wait flag is cleared, active thread events are allowed.

Call relations: This test covers the gate between startup setup and normal event processing. It links the wait decision, the stop-waiting decision, and the event-handling decision into one expected sequence.

Call graph: calls 1 internal fn (new); 3 external calls (assert_eq!, should_stop_waiting_for_initial_session, should_wait_for_initial_session).

fn startup_waiting_gate_not_applied_for_resume_or_fork_session_selection()

Purpose: This test confirms that resumed and forked sessions do not use the fresh-start waiting gate. Those paths already point at an existing thread target, so event processing should not be blocked in the same way.

Data flow: It creates resume and fork selections, asks whether each should wait for an initial session, and then asks whether active thread events should be handled. In both cases, the wait value allows event handling to continue.

Call relations: This test complements the fresh-start gate tests by checking the opposite paths. It protects resume and fork startup from accidentally being slowed or frozen by logic meant only for brand-new sessions.

Call graph: calls 1 internal fn (new); 5 external calls (from, assert_eq!, should_wait_for_initial_session, Fork, Resume).

async fn startup_thread_started_submits_queued_startup_input()

Purpose: This asynchronous test checks that text typed before the startup thread is ready is not lost. Once the server reports that the startup thread exists, the queued message should be submitted as the first user turn.

Data flow: It creates a test app with communication channels, marks startup as pending, tells the chat widget to queue submissions, inserts text as if the user typed it, and simulates pressing Enter. The text first appears in the chat widget’s queue. Then a test app server is started, a new thread-started result is delivered, and the test reads the outgoing operation channel. The result should be a user-turn operation containing the queued text.

Call relations: This test drives the realistic handoff from early user input to server-backed session startup. It checks that handle_startup_thread_started drains the chat widget’s queued message into the normal operation stream after the thread is attached.

Call graph: calls 1 internal fn (new); 6 external calls (pin, new, new, assert_eq!, start_embedded_app_server_for_picker, panic!).

async fn startup_thread_start_failure_returns_error()

Purpose: This asynchronous test checks that a failed fresh-session start produces a clear error and leaves the app in a safe state. The app should not remain stuck thinking startup is still pending.

Data flow: It creates a test app, marks startup as pending, starts a test embedded server, and then calls the startup-thread completion path with an error string instead of a successful thread. The result should be an error message that includes the server failure. The app’s pending flag is cleared and no primary thread is set.

Call relations: This test covers the failure branch of the same startup-thread handler used by successful startup. It ensures that callers get a real error back instead of continuing with a half-created chat session.

Call graph: 4 external calls (pin, assert!, assert_eq!, start_embedded_app_server_for_picker).

fn stale_startup_thread_started_removes_local_routing_state() -> Result<()>

Purpose: This test verifies that if an outdated startup-thread result arrives for a thread that is no longer the active primary thread, the app removes local routing data for that stale thread. This avoids sending future events to the wrong place.

Data flow: It builds a test runtime, creates an app and server, assigns one thread as the primary active thread, and separately inserts local channel and navigation state for another stale thread. Then it delivers a startup-thread-started result for the stale thread. Afterward, the stale thread’s channel and navigation entry are gone, while the active thread remains the original primary thread.

Call relations: This test exercises cleanup inside the startup-thread completion path. It matters when timing is awkward: a late result for an old thread should not disturb the currently active conversation.

Call graph: calls 2 internal fn (new, new); 5 external calls (new, assert!, assert_eq!, start_embedded_app_server_for_picker, new_multi_thread).

async fn ignore_same_thread_resume_reports_noop_for_current_thread()

Purpose: This asynchronous test checks that trying to resume the exact thread already being viewed is ignored and reported politely. The user should get an informational message rather than causing a duplicate reattach.

Data flow: It creates a test app with event channels, creates a thread session, loads it into the chat widget, registers the matching thread channel, and makes it active. After clearing old app events, it asks the app whether the resume target should be ignored. The answer is true, and the app emits a history cell saying the user is already viewing that project.

Call relations: This test focuses on the resume shortcut that runs before doing heavier resume work. It confirms that the app detects the current active thread and sends a small user-facing message through the app event stream.

Call graph: calls 2 internal fn (new, new_with_session); 3 external calls (new, assert!, panic!).

async fn ignore_same_thread_resume_allows_reattaching_displayed_inactive_thread()

Purpose: This asynchronous test checks that the app does not ignore every resume target that happens to be displayed. If the thread is shown in the chat widget but is not the active routed thread, reattaching should still be allowed.

Data flow: It creates a test app, creates a thread session, and loads that session into the chat widget without registering and activating the matching thread channel. It then asks whether resuming that target should be ignored. The result is false, and no informational transcript cell is added.

Call relations: This test covers the boundary case for the same-thread resume check. It ensures the no-op behavior is reserved for the truly current active thread, while inactive displayed sessions can still go through the normal reattach path.

Call graph: calls 1 internal fn (new); 1 external calls (assert!).

fn agent_status_uses_bounded_buffered_activity()

Purpose: This test verifies that the agent status display does not include unlimited command output. It should show the command that ran and a concise agent message, but not flood the UI with the command's captured output.

Data flow: The test starts with an empty ThreadEventStore, which is a bounded record of recent thread events. It adds a completed command event containing a very large aggregated_output, then adds a completed agent message. It converts the store into a preview, renders that preview into display lines, joins those lines into plain text, and checks the final text against the expected snapshot. The final assertion confirms that the huge output text never appears.

Call relations: During the test run, the Rust test runner calls this function. Inside it, the test creates the event store with ThreadEventStore::new, records completed notifications, builds the user-facing preview with AgentStatusThreadPreview::from_store, wraps it in AgentStatusHistoryCell::new, and asks the cell to render its lines. The snapshot assertion checks the intended UI text, while the explicit assertion guards against accidentally showing the oversized command output.

Call graph: calls 4 internal fn (new, from_store, new, try_from); 5 external calls (ItemCompleted, new, assert!, assert_snapshot!, vec!).

fn agent_status_uses_reasoning_summaries_only()

Purpose: This test verifies that the agent status display shows only safe reasoning summaries, not raw reasoning content. It protects the UI from exposing internal reasoning text when a shorter summary is available, and from showing raw-only reasoning when no summary exists.

Data flow: The test creates an empty ThreadEventStore and adds two completed reasoning items. One has both a summary and raw content; the other has only raw content. The store is turned into an agent preview, rendered as display text, and compared with a snapshot that contains only the safe summary. The final assertions confirm that neither piece of raw reasoning text appears in the rendered output.

Call relations: The Rust test runner calls this function as part of the test suite. The function follows the same path the real UI uses: events go into ThreadEventStore, AgentStatusThreadPreview::from_store extracts what should be shown, and AgentStatusHistoryCell::new prepares it for rendering. The snapshot checks the visible result, and the explicit assertions make the privacy rule clear: summaries may be shown, raw reasoning must not be.

Call graph: calls 3 internal fn (new, from_store, new); 5 external calls (ItemCompleted, new, assert!, assert_snapshot!, vec!).

fn desktop_thread_opened_history_snapshot()

Purpose: This test verifies the displayed history entry for the normal “desktop thread opened” message. It helps catch accidental changes to the wording, spacing, or formatting of that success message.

Data flow: It starts with the standard desktop-thread-opened text and creates an informational history cell from it. That cell is rendered into a plain multiline string, and the string is compared against the saved snapshot named desktop_thread_opened_history. Nothing is returned; the test either passes or reports a mismatch.

Call relations: During the test run, this function creates its test data by calling new_info_event. It then relies on the snapshot assertion to compare the rendered result with the stored expected output.

Call graph: 2 external calls (new_info_event, assert_snapshot!).

fn desktop_thread_open_error_history_snapshot()

Purpose: This test verifies the displayed history entry for an error that happens while opening a desktop thread. It makes sure the failure message remains readable and formatted as expected.

Data flow: It starts with the sample failure detail launch failed, turns that into the app’s desktop-thread-open-error message, and wraps it in an error history cell. The cell is rendered into plain text and compared with the saved snapshot named desktop_thread_open_error_history. The test changes no application state; it only succeeds or fails based on the comparison.

Call relations: During the test run, this function builds the error cell by calling new_error_event. It then hands the rendered text to the snapshot assertion so any unexpected UI change is caught.

Call graph: 2 external calls (new_error_event, assert_snapshot!).

fn render_cell(cell: &impl HistoryCell) -> String

Purpose: This helper turns a history cell into the exact multiline text used by the snapshot tests. It keeps the tests focused on what the user would actually see.

Data flow: It receives a history cell as input. It asks the cell for its display lines at a fixed width of 80 characters, converts each line to a string, and joins those strings with newline characters. The output is one plain String containing the rendered cell.

Call relations: The snapshot tests use this helper before comparing output. Internally, it calls the cell’s display_lines method, which supplies the formatted lines that represent the cell on screen.

Call graph: 1 external calls (display_lines).

fn app_scoped_key_path_quotes_dotted_app_ids()

Purpose: This test confirms that app IDs containing dots are treated as one app name, not as nested configuration sections. It protects configuration updates for plugins or apps whose identifiers include periods.

Data flow: It starts with the app ID "plugin.linear" and the setting name "enabled". It asks the configuration helper to build the key path, then compares the result with the expected string apps."plugin.linear".enabled. Nothing is changed outside the test; the output is simply pass or fail.

Call relations: During the test run, this function calls the external assert_eq! comparison macro. The story is: build the path, compare it to the known-correct path, and fail the test if quoting was lost.

Call graph: 1 external calls (assert_eq!).

fn trusted_project_edit_targets_project_trust_level()

Purpose: This test confirms that the helper for trusting a project creates the exact configuration edit needed to mark that project as trusted. It matters because a wrong key path could change the wrong project or the wrong setting.

Data flow: It starts with the project path /workspace/team.project. It passes that path into the helper, receives a ConfigEdit, and compares it to the expected edit: the project path is quoted inside the configuration key, the target field is trust_level, the value is trusted, and the update replaces the old value. The test only checks the returned data; it does not write any configuration.

Call relations: When the test suite runs, this function calls the external assert_eq! macro to compare the produced edit with the expected one. It verifies the helper’s output before any real configuration update code would rely on it.

Call graph: 1 external calls (assert_eq!).

fn format_config_error_preserves_server_validation_message()

Purpose: This test makes sure a formatted configuration error keeps the server’s original validation message. That is important because the server often explains exactly why a setting was rejected.

Data flow: It creates an example error saying that a batch configuration write failed because features.fast_mode=true violates managed requirements. It then wraps that error with extra TUI context, formats it, and compares the final message with the expected full text. The result is a pass or fail showing whether the useful underlying error was preserved.

Call relations: During the test run, this function uses the external eyre! macro to create the sample error and assert_eq! to check the final formatted text. It exercises the error-formatting path that would be used after a real failed configuration write.

Call graph: 2 external calls (assert_eq!, eyre!).

fn external_agent_config_migration_messages_snapshot()

Purpose: This test checks that all migration-related user messages match the approved saved version. It is used to catch accidental changes to text that appears in the terminal interface.

Data flow: It starts with three sample item counts: 0, 1, and 2. It turns those counts into success messages, adds several fixed migration status or error messages, joins everything into one text block, and sends that block to the snapshot checker. The output is not returned to the app; instead, the test either passes because the text matches the stored snapshot or fails because it changed.

Call relations: During the test run, this function is called by the Rust test framework. It relies on the migration message constants and helper function imported from the parent module, then hands the final combined text to assert_snapshot!, which compares it with the stored expected output.

Call graph: 1 external calls (assert_snapshot!).

fn load_local_chatgpt_auth(
    codex_home: &Path,
    auth_credentials_store_mode: AuthCredentialsStoreMode,
    forced_chatgpt_workspace_id: Option<&[String]>,
) -> Result<LocalChatgptAuth, String>

Purpose: This function loads a saved local ChatGPT login and turns it into a small, easy-to-use LocalChatgptAuth value. It also guards against common mistakes: no auth file, API-key auth instead of ChatGPT auth, missing token data, missing workspace ID, or a workspace that is not allowed.

Data flow: It receives a Codex home folder path, a setting that says where credentials are stored, and an optional list of allowed ChatGPT workspace IDs. It reads the saved auth data, checks that it represents a ChatGPT login, pulls out the access token, workspace account ID, and plan type, lowercases the plan type, and returns those fields together. If anything is missing or invalid, it returns a plain error message instead of auth data.

Call relations: The test cases call this function as the thing being verified. It relies on the login library’s auth-loading routine to read the saved auth file or credential store, then performs its own ChatGPT-specific checks before handing back a simplified auth object to the caller.

Call graph: calls 1 internal fn (default); called by 5 (loads_local_chatgpt_auth_from_managed_auth, prefers_managed_auth_over_external_ephemeral_tokens, preserves_usage_based_plan_type_wire_name, rejects_api_key_auth, rejects_missing_local_auth); 3 external calls (load_auth_dot_json, format!, matches!).

fn fake_jwt(email: &str, account_id: &str, plan_type: &str) -> String

Purpose: This helper creates a fake JWT, which is a three-part token string often used to carry login claims. Here it is only used in tests, so the token is shaped like a real one but is not meant to be secure.

Data flow: It receives an email address, a ChatGPT account ID, and a plan type. It builds a small JSON header and payload, base64-encodes them, adds a fake signature, and returns one token-shaped string containing the supplied account and plan information.

Call relations: Other test helpers and tests call this when they need realistic-looking ChatGPT tokens. It feeds token strings into tests::write_chatgpt_auth and into the external token-login helper used by the managed-auth preference test.

Call graph: 3 external calls (format!, json!, to_vec).

fn write_chatgpt_auth(codex_home: &Path, plan_type: &str)

Purpose: This helper writes a complete fake ChatGPT login into a temporary Codex home folder. Tests use it to set up the local auth state that load_local_chatgpt_auth should later read.

Data flow: It receives a Codex home folder path and a plan type. It creates fake ID and access tokens, parses the ID token into claim data, builds an auth record with workspace workspace-1, and saves that record using file-based credential storage. Its output is the changed test folder, now containing saved ChatGPT auth.

Call relations: Several tests call this before calling load_local_chatgpt_auth. It sits between tests::fake_jwt, which supplies token strings, and the auth-saving library call, which writes the finished fake login to disk.

Call graph: calls 2 internal fn (default, parse_chatgpt_jwt_claims); 3 external calls (now, save_auth, fake_jwt).

fn loads_local_chatgpt_auth_from_managed_auth()

Purpose: This test proves that a normal saved ChatGPT login can be read successfully. It checks that the workspace ID, plan type, and access token come back as expected.

Data flow: It creates a temporary Codex home folder, writes fake ChatGPT auth for workspace-1, then calls load_local_chatgpt_auth while allowing that workspace. It expects a successful result and checks that the returned account ID is workspace-1, the plan is business, and the access token is not empty.

Call relations: This is the basic happy-path caller of load_local_chatgpt_auth. It uses tests::write_chatgpt_auth to prepare the saved auth, then verifies that the main loader returns the simplified auth data.

Call graph: calls 1 internal fn (load_local_chatgpt_auth); 4 external calls (new, assert!, assert_eq!, write_chatgpt_auth).

fn rejects_missing_local_auth()

Purpose: This test proves that the loader gives a clear failure when there is no saved local auth. That matters because silently continuing without credentials would make later failures harder to understand.

Data flow: It creates an empty temporary Codex home folder and calls load_local_chatgpt_auth without any allowed-workspace restriction. Because no auth has been saved, it expects an error and checks that the message says no local auth available.

Call relations: This test calls load_local_chatgpt_auth directly in the missing-auth case. It verifies one of the loader’s early failure paths.

Call graph: calls 1 internal fn (load_local_chatgpt_auth); 2 external calls (new, assert_eq!).

fn rejects_api_key_auth()

Purpose: This test proves that API-key credentials are not accepted as a ChatGPT login. The two auth styles are different, and this loader specifically needs ChatGPT token data with a workspace identity.

Data flow: It creates a temporary Codex home folder, saves an auth record marked as API-key auth, then calls load_local_chatgpt_auth. It expects the call to fail and checks that the error says the local auth is not a ChatGPT login.

Call relations: This test prepares auth data using the external save routine, then calls load_local_chatgpt_auth to confirm that the loader rejects the wrong credential type before trying to use token fields.

Call graph: calls 2 internal fn (default, load_local_chatgpt_auth); 3 external calls (new, assert_eq!, save_auth).

fn prefers_managed_auth_over_external_ephemeral_tokens()

Purpose: This test proves that the locally managed saved ChatGPT auth is the one used, even if separate external temporary tokens also exist. This prevents an outside token source from unexpectedly changing which workspace the test uses.

Data flow: It creates a temporary Codex home folder, writes managed ChatGPT auth for workspace-1, then saves external ephemeral token data for workspace-2. It calls load_local_chatgpt_auth while allowing both workspaces, and checks that the returned account and plan still come from workspace-1.

Call relations: This test uses tests::write_chatgpt_auth for the managed login, tests::fake_jwt plus the login helper for the external token, and then calls load_local_chatgpt_auth to verify the loader’s choice.

Call graph: calls 1 internal fn (load_local_chatgpt_auth); 5 external calls (new, assert_eq!, login_with_chatgpt_auth_tokens, fake_jwt, write_chatgpt_auth).

fn preserves_usage_based_plan_type_wire_name()

Purpose: This test makes sure a specific ChatGPT plan name is preserved exactly as the system expects to send or compare it. In particular, the usage-based business plan string must not be renamed or simplified.

Data flow: It creates a temporary Codex home folder, writes fake ChatGPT auth whose plan type is self_serve_business_usage_based, then calls load_local_chatgpt_auth. It expects the returned plan type to match that same string.

Call relations: This test uses tests::write_chatgpt_auth to create the saved login and then calls load_local_chatgpt_auth to check the plan-type extraction and normalization behavior.

Call graph: calls 1 internal fn (load_local_chatgpt_auth); 3 external calls (new, assert_eq!, write_chatgpt_auth).

async fn dismiss_version_creates_cache_file_when_missing()

Purpose: This test proves that dismissing an update version creates the update cache file if it is missing. It protects the fresh-install case, where the app has no saved update information yet.

Data flow: It starts with an empty temporary folder and builds a config that uses that folder as the app home. It asks for the expected version-cache path, dismisses version 999.0.0, then reads the cache file back. The expected result is a cache record whose dismissed version and latest version are both 999.0.0, while the last-checked time remains the Unix epoch.

Call relations: During the test, it uses a temporary directory helper to isolate the filesystem work, a default config builder to make a realistic configuration, and assertion helpers to compare the saved cache data with the expected values. It exercises the real update-cache functions indirectly as a user action would: dismiss first, then read the stored result.

Call graph: 3 external calls (assert_eq!, default, tempdir).

fn paste_burst_newline_does_not_submit_short_first_line()

Purpose: This test makes sure a very quick newline after a short first line is treated as part of pasted multi-line text, not as a submit action. It covers short first lines such as x, id, and foo because those are easy cases to accidentally submit too early.

Data flow: The test starts with a fresh prompt and a receiver that records submitted text. It sends characters from a first line, then an Enter almost immediately, then more characters for a second line. At that point, it expects nothing to have been submitted and the prompt to still be open. It then sends a later Enter, and expects the full two-line text to come out through the receiver and the prompt to be marked complete.

Call relations: This test calls custom_prompt_view to build the prompt and submission mailbox, and uses elapsed to create controlled timestamps for each fake key press. It drives CustomPromptView directly by feeding it key events, then checks the receiver to prove whether the prompt submitted or kept editing.

Call graph: calls 2 internal fn (custom_prompt_view, elapsed); 5 external calls (now, Char, from, assert!, assert_eq!).

fn paste_burst_newline_after_tab_does_not_submit()

Purpose: This test checks that a fast Enter after a Tab is also treated as paste-related input rather than a submit command. It protects a case where Tab may affect the prompt text or cursor behavior before the pasted newline arrives.

Data flow: The test creates a new prompt and sends x, then Tab, then Enter, all only milliseconds apart. It then sends the rest of the pasted text. Before the final delayed Enter, the receiver should still be empty and the view should not be complete. After the delayed Enter, the receiver should contain the intended multi-line text and the view should be complete.

Call relations: Like the other paste tests, it relies on custom_prompt_view for a controlled prompt and elapsed for precise fake timing. It exercises the same key-event path as real terminal input would, then observes the submit callback indirectly through the receiver.

Call graph: calls 2 internal fn (custom_prompt_view, elapsed); 5 external calls (now, Char, from, assert!, assert_eq!).

fn delayed_enter_after_typing_submits()

Purpose: This test confirms the normal behavior: when a user types text and presses Enter after a noticeable pause, the prompt submits. It makes sure the paste protection does not stop ordinary single-line submission.

Data flow: The test creates a prompt, sends the characters f, o, and o with realistic gaps, then sends Enter later. The prompt should send foo through the receiver and mark itself complete.

Call relations: This is the balancing test for the paste-burst cases. It uses custom_prompt_view and elapsed in the same way, but with slower timing so the prompt should hand the entered text to its submit callback.

Call graph: calls 2 internal fn (custom_prompt_view, elapsed); 5 external calls (now, Char, from, assert!, assert_eq!).

fn custom_prompt_view() -> (CustomPromptView, Receiver<String>)

Purpose: This helper builds a test-ready CustomPromptView and a way to observe what it submits. It keeps the tests focused on typing behavior instead of repeating setup code.

Data flow: It creates a channel, which is a simple sender-and-receiver pair for passing text inside the test. It builds a prompt with a title, instructions, empty starting text, no context label, and a callback that sends submitted text into the channel. It returns the prompt and the receiving end of the channel.

Call relations: All three tests call this helper at the start. The helper hands them a fresh prompt to drive and a receiver they can check after simulated key presses to see whether submission happened.

Call graph: calls 1 internal fn (new); called by 3 (delayed_enter_after_typing_submits, paste_burst_newline_after_tab_does_not_submit, paste_burst_newline_does_not_submit_short_first_line); 3 external calls (new, new, channel).

fn elapsed(ms: usize) -> std::time::Duration

Purpose: This helper turns a number of milliseconds into a duration value. It makes the test timelines easy to read.

Data flow: It takes a millisecond count as input, converts it to the time-duration type used by Rust, and returns that duration. The tests add this duration to a starting instant to create precise event times.

Call relations: The timing-sensitive tests call this helper whenever they need to place a fake key press on the timeline. Those times are then passed into the prompt so it can decide whether input looks like a paste burst or a deliberate Enter press.

Call graph: called by 3 (delayed_enter_after_typing_submits, paste_burst_newline_after_tab_does_not_submit, paste_burst_newline_does_not_submit_short_first_line); 1 external calls (from_millis).

fn thread_settings_for_test(
    model: &str,
    thread_id: ThreadId,
) -> codex_app_server_protocol::ThreadSettingsUpdatedNotification

Purpose: Builds a realistic “thread settings updated” server notification for tests. It lets tests focus on what should happen after settings change, without repeating a large settings object each time.

Data flow: It receives a model name and a thread identifier. It fills in a complete settings update with that thread id, the model, a read-only permission profile, approval behavior, reasoning effort, service tier, collaboration mode, and personality. It returns the finished notification object for a test to feed into the chat widget.

Call relations: The thread settings tests call this helper when they need to simulate the app server saying, “This thread’s settings have changed.” It uses the shared read-only permission profile builder so the generated settings match the real permission model.

Call graph: calls 1 internal fn (read_only); called by 2 (thread_settings_updated_preserves_default_settings_for_plan_mode, thread_settings_updated_updates_visible_state_without_transcript); 1 external calls (to_string).

fn configured_thread_session(thread_id: ThreadId) -> crate::session_state::ThreadSessionState

Purpose: Creates a baseline thread session state for tests. This gives the chat widget an initial, known state before a server update is applied.

Data flow: It receives a thread identifier. It builds a session state with a model, provider, approval policy, read-only permissions, working directory, workspace roots, and empty optional fields such as history and collaboration mode. It returns that session state so a test can install it into the widget.

Call relations: The thread settings tests call this before sending update notifications. It prepares the widget with a visible thread, so later checks can prove that only matching thread updates affect the screen.

Call graph: calls 1 internal fn (read_only); called by 2 (thread_settings_updated_preserves_default_settings_for_plan_mode, thread_settings_updated_updates_visible_state_without_transcript); 2 external calls (new, vec!).

async fn invalid_url_elicitation_is_declined()

Purpose: Checks that the widget refuses a URL-based elicitation request when the request belongs to a different thread than the one currently visible. An elicitation request is the server asking the user for some extra action or input.

Data flow: The test creates a chat widget, gives it one visible thread id, then sends an elicitation request for a different thread id. The widget turns that into a submitted thread operation that declines the request. The test reads the outgoing event and verifies the decline goes to the request’s thread and server name.

Call relations: The async test runner invokes this test. Inside the test, the widget’s elicitation request path is exercised directly, and the result is checked through the app event receiver.

Call graph: calls 1 internal fn (new); 2 external calls (Integer, assert_matches!).

async fn thread_settings_updated_updates_visible_state_without_transcript()

Purpose: Verifies that a settings update for the currently visible thread changes the widget’s active model, reasoning effort, approvals, permissions, personality, and collaboration mode. It also checks that this kind of update does not add chat history.

Data flow: The test starts a widget with an initial model, installs a configured thread session, drains any setup history, then sends a matching thread settings update. It reads the widget’s current settings and confirms they changed. It then sends an update for a different thread and confirms the visible model stays unchanged.

Call relations: The test runner calls this test. It relies on configured_thread_session to create the starting state and thread_settings_for_test to create server update messages, then drives the widget through handle_server_notification.

Call graph: calls 3 internal fn (new, configured_thread_session, thread_settings_for_test); 3 external calls (ThreadSettingsUpdated, assert!, assert_eq!).

async fn thread_settings_updated_preserves_default_settings_for_plan_mode()

Purpose: Checks that switching into plan collaboration mode uses the plan-mode settings while preserving the original default-mode settings for later. This prevents a temporary mode switch from overwriting the user’s normal model choice.

Data flow: The test gives the widget a thread whose default model and reasoning effort are known. It saves the default collaboration mode, sends a server update that activates plan mode with a different model and effort, and confirms those plan values are shown. Then it switches back to the default mask and confirms the original default model and effort return.

Call relations: The test runner invokes this test. It uses configured_thread_session for the starting session, thread_settings_for_test for the plan-mode update, and the collaboration mode default mask helper to switch back to default mode.

Call graph: calls 4 internal fn (new, configured_thread_session, thread_settings_for_test, default_mask); 2 external calls (ThreadSettingsUpdated, assert_eq!).

async fn collab_spawn_end_shows_requested_model_and_effort()

Purpose: Checks that when a collaborative agent spawn finishes, the history line still shows the model and reasoning effort that were requested at the start. This protects useful context for the user even if the completed server item omits those fields.

Data flow: The test creates a widget, records metadata for the spawned agent, sends an in-progress spawn item containing model and effort, then sends a completed spawn item naming the new agent but leaving model and effort empty. It drains rendered history, joins it into text, and checks that the spawn line includes the agent name, role, model, and effort.

Call relations: The test runner calls this test. It drives the widget with ItemStarted and ItemCompleted notifications and then checks the rendered history emitted through the app event receiver.

Call graph: calls 1 internal fn (new); 7 external calls (from, new, ItemCompleted, ItemStarted, new, assert!, vec!).

async fn live_app_server_user_message_item_completed_does_not_duplicate_rendered_prompt()

Purpose: Makes sure a user’s prompt is not shown twice when the server later confirms the same user message. The widget already renders the prompt immediately when the user presses Enter.

Data flow: The test types text into the composer, sends Enter, and confirms one user-turn operation is submitted and one prompt cell appears. It then simulates the app server completing a matching user message item. After that, it drains history again and expects nothing new.

Call relations: The async test runner invokes this test. The test exercises both local keyboard submission and later ItemCompleted server notification handling, proving the two paths cooperate instead of duplicating output.

Call graph: calls 1 internal fn (new); 7 external calls (new, ItemCompleted, new, assert!, assert_eq!, panic!, vec!).

async fn live_app_server_turn_completed_clears_working_status_after_answer_item()

Purpose: Checks that the “Working” status remains visible while a turn is in progress and disappears only when the turn is completed. This keeps the user from seeing the task as done too early.

Data flow: The test sends a turn-started notification and confirms the bottom pane shows a running task with a “Working” header. It then sends a completed final answer item and confirms the answer appears while the task still looks active. Finally, it sends a turn-completed notification and confirms the running indicator and status widget are gone.

Call relations: The test runner calls this test. It walks through the normal server sequence of TurnStarted, ItemCompleted for the answer, and TurnCompleted, checking the widget state after each step.

Call graph: 6 external calls (ItemCompleted, TurnCompleted, TurnStarted, new, assert!, assert_eq!).

async fn live_app_server_turn_started_sets_feedback_turn_id()

Purpose: Verifies that feedback submitted during a turn is tagged with that turn’s id. This helps connect a bug report or feedback note to the exact server turn it came from.

Data flow: The test sends a turn-started notification with a known id. It opens a bug feedback note, submits it with Enter, and reads the outgoing feedback event. The event must include the same turn id and the chosen category.

Call relations: The test runner invokes this test. It first exercises server notification handling to set the active turn, then exercises the feedback UI path and checks the resulting app event.

Call graph: 4 external calls (new, TurnStarted, new, assert_matches!).

async fn live_app_server_warning_notification_renders_message()

Purpose: Checks that a general server warning is rendered into chat history with its message intact. This ensures users see important non-fatal problems.

Data flow: The test sends a warning notification containing a long message about a skills context budget. It drains rendered history, normalizes whitespace, and verifies both the summary and guidance text are present.

Call relations: The async test runner calls this test. It drives the widget through the Warning notification path and checks the history cell sent to the UI event stream.

Call graph: 3 external calls (Warning, assert!, assert_eq!).

async fn live_app_server_guardian_warning_notification_renders_message()

Purpose: Checks that an automatic approval review warning appears in chat history. This tells the user when a requested action was denied by the review layer.

Data flow: The test sends a guardian warning notification with a clear denial message. It drains history and confirms exactly one warning cell appears and contains that message.

Call relations: The test runner invokes this test. It exercises the GuardianWarning notification branch and verifies the rendered result.

Call graph: 3 external calls (GuardianWarning, assert!, assert_eq!).

async fn live_app_server_config_warning_prefixes_summary()

Purpose: Checks that configuration warnings from the server are shown to the user. A configuration warning means the app found a problem in settings and may be falling back to defaults.

Data flow: The test sends a config warning with a summary and no details. It drains history and confirms one warning cell contains the summary text.

Call relations: The test runner calls this test. It feeds a ConfigWarning notification into the widget and inspects the resulting history output.

Call graph: 3 external calls (ConfigWarning, assert!, assert_eq!).

async fn live_app_server_file_change_item_started_preserves_changes()

Purpose: Verifies that a file-change item still renders a useful patch summary as soon as it starts. This helps users see what file is being added or edited while work is underway.

Data flow: The test sends an in-progress file change for foo.txt with an add-style diff. It drains history and checks the last rendered patch cell mentions foo.txt as added or edited.

Call relations: The async test runner invokes this test. It exercises the ItemStarted path for file changes and checks that the patch renderer receives and preserves the change details.

Call graph: 3 external calls (ItemStarted, assert!, vec!).

async fn live_app_server_command_execution_strips_shell_wrapper()

Purpose: Checks that command history shows the meaningful command instead of the surrounding shell wrapper. For example, users should see the Python command, not just the technical /bin/zsh -lc ... envelope used to run it.

Data flow: The test builds a shell-wrapped command string, sends an in-progress command execution notification, then sends a completed command execution notification with output, exit code, and duration. It drains history and compares the rendered command cell to a saved snapshot.

Call relations: The test runner calls this test. It uses the command start and completion notification paths, and the snapshot assertion records the expected user-facing rendering.

Call graph: 6 external calls (ItemCompleted, ItemStarted, assert_chatwidget_snapshot!, assert_eq!, try_join, vec!).

async fn live_app_server_collab_wait_items_render_history()

Purpose: Checks that waiting on collaborative agents produces clear history output. This lets users see which agents were waited on and what state they ended in.

Data flow: The test creates fixed thread ids for a sender and two receivers, assigns names and roles to the receivers, sends a wait tool call start, then sends its completion with one agent completed and another still running. It drains all rendered history, joins it, and compares it to a snapshot.

Call relations: The test runner invokes this test. It exercises collaborative agent ItemStarted and ItemCompleted handling, with metadata lookup used to display human-friendly agent labels.

Call graph: calls 1 internal fn (from_string); 6 external calls (from, new, ItemCompleted, ItemStarted, assert_chatwidget_snapshot!, vec!).

async fn live_app_server_collab_spawn_completed_renders_requested_model_and_effort()

Purpose: Checks that a completed collaborative-agent spawn item renders the requested model and reasoning effort. This makes the spawned agent’s setup visible in the transcript.

Data flow: The test sends a spawn-agent start notification with a prompt, model, and effort. It then sends a completed spawn notification naming the spawned thread and repeating the model and effort. It drains the rendered history and compares it to a snapshot.

Call relations: The async test runner calls this test. It drives the widget through the collaborative spawn start and completion paths and uses a snapshot to protect the exact rendered wording.

Call graph: calls 1 internal fn (from_string); 7 external calls (from, new, ItemCompleted, ItemStarted, new, assert_chatwidget_snapshot!, vec!).

async fn live_app_server_failed_turn_does_not_duplicate_error_history()

Purpose: Makes sure the same failure is not printed twice when both an error notification and a failed turn completion report it. This avoids noisy, confusing chat history.

Data flow: The test starts a turn, sends an error notification saying “permission denied,” and confirms one history cell appears. It then sends a turn-completed notification for the same failed turn with the same error. It expects no extra history and confirms the task is no longer running.

Call relations: The test runner invokes this test. It covers the interaction between the Error notification path and the TurnCompleted failure path, checking that they share enough state to avoid duplicate rendering.

Call graph: 6 external calls (Error, TurnCompleted, TurnStarted, new, assert!, assert_eq!).

async fn live_app_server_failed_turn_consolidates_streamed_answer()

Purpose: Checks that if a turn fails after partial streamed text has appeared, the partial text is first consolidated into normal history. This prevents losing streamed content when the stream controller is cleared.

Data flow: The test starts a turn, sends an agent-message delta containing a partial diff block, runs a commit tick so streaming output can be processed, then sends an error. It reads outgoing events until it finds a consolidate-agent-message event and verifies the saved source includes the streamed patch text.

Call relations: The test runner calls this test. It relies on shared test helpers for starting a turn, sending a stream delta, and sending an error, then checks that failure cleanup hands partial stream content to the consolidation path.

Call graph: 1 external calls (assert!).

async fn live_app_server_stream_recovery_restores_previous_status_header()

Purpose: Verifies that after a temporary retrying error, receiving new streamed content restores the normal “Working” status. This keeps a reconnect warning from sticking around after the stream has recovered.

Data flow: The test starts a turn, sends a retryable error with a “Reconnecting” message, then sends an agent-message delta. It checks the bottom status widget and confirms the header is back to “Working,” details are cleared, and retry status tracking is reset.

Call relations: The async test runner invokes this test. It exercises the sequence TurnStarted, retryable Error, then AgentMessageDelta to prove stream recovery resets the status display.

Call graph: 6 external calls (AgentMessageDelta, Error, TurnStarted, new, assert!, assert_eq!).

async fn live_app_server_server_overloaded_error_renders_warning()

Purpose: Checks that a server-overloaded error is shown as a concise warning and stops the running task indicator. This gives the user a clear reason for failure without extra clutter.

Data flow: The test starts a turn, drains any start output, then sends a non-retryable error marked as server overloaded. It expects one rendered warning cell exactly saying “ server overloaded” and confirms the bottom pane is no longer running.

Call relations: The test runner calls this test. It drives the Error notification path with a specific error code so the widget can choose the correct user-facing warning style.

Call graph: 5 external calls (Error, TurnStarted, new, assert!, assert_eq!).

async fn live_app_server_cyber_policy_error_renders_dedicated_notice()

Purpose: Checks that a cybersecurity policy error shows a special explanatory notice instead of the raw server fallback message. This gives users a clearer and safer explanation of what happened.

Data flow: The test starts a turn, then sends a non-retryable error marked as a cybersecurity policy issue with a fallback message. It drains history and confirms the rendered notice mentions possible cybersecurity risk and Trusted Access for Cyber, does not include the fallback message, and clears the running task.

Call relations: The async test runner invokes this test. It exercises the special CyberPolicy branch in error rendering after a normal TurnStarted notification.

Call graph: 5 external calls (Error, TurnStarted, new, assert!, assert_eq!).

async fn live_app_server_model_verification_renders_warning()

Purpose: Checks that model verification warnings are rendered when extra safety checks are enabled. This informs users that the chat has been flagged for additional review conditions.

Data flow: The test sends a model verification notification containing the Trusted Access for Cyber verification. It drains history and verifies one warning cell mentions multiple cybersecurity-risk flags, extra safety checks, the verification name, and the help URL.

Call relations: The test runner calls this test. It feeds a ModelVerification notification into the widget and checks the warning text produced for the transcript.

Call graph: 4 external calls (ModelVerification, assert!, assert_eq!, vec!).

async fn live_app_server_invalid_thread_name_update_is_ignored()

Purpose: Verifies that a malformed thread id in a thread-name update does not corrupt the current thread state. Bad server data should not overwrite the visible thread name.

Data flow: The test sets the widget to a known thread id and thread name. It sends a thread-name update whose thread id string is invalid. It then confirms the widget still has the original thread id and original name.

Call relations: The async test runner invokes this test. It exercises the ThreadNameUpdated notification path with invalid input and checks that validation protects existing state.

Call graph: calls 1 internal fn (new); 2 external calls (ThreadNameUpdated, assert_eq!).

async fn live_app_server_thread_name_update_shows_resume_hint()

Purpose: Checks that a valid thread-name update changes the widget’s thread name and renders a resume hint. The resume hint helps users know how to return to the named thread later.

Data flow: The test sets the widget’s current thread id, sends a matching thread-name update with the name “review-fix,” and confirms the internal name changes. It then drains one rendered history cell and compares it to a snapshot.

Call relations: The test runner calls this test. It drives the valid ThreadNameUpdated path and uses a snapshot to protect the exact resume-hint rendering.

Call graph: calls 1 internal fn (from_string); 3 external calls (ThreadNameUpdated, assert_chatwidget_snapshot!, assert_eq!).

async fn live_app_server_thread_closed_requests_immediate_exit()

Purpose: Checks that when the server says the thread is closed, the widget asks the app to exit immediately. This prevents the user interface from staying open on a conversation that no longer exists.

Data flow: The test sends a thread-closed notification. It reads the next app event and verifies it is an immediate exit request.

Call relations: The async test runner invokes this test. It exercises the ThreadClosed notification path and checks the widget’s outgoing event channel for the shutdown signal.

Call graph: 2 external calls (ThreadClosed, assert_matches!).

async fn exec_approval_emits_proposed_command_and_decision_history()

Purpose: This test checks the basic command approval experience. It makes sure a proposed command is shown in the approval modal, not immediately written into chat history, and that approving it creates the expected decision record.

Data flow: It starts with a fresh chat widget and a fake command approval request for echo hello world. The request is passed into the widget, the widget is rendered into an in-memory terminal buffer, and the saved snapshot checks what the user would see. Then the test simulates pressing y, reads the emitted history item, and compares it to the expected approved-command text.

Call relations: The async test runner calls this test. Inside the story, the test creates current-directory path data, builds key events and a rendering buffer, then relies on assertions and snapshot checks to confirm that the approval modal and the later history entry stay correct.

Call graph: calls 1 internal fn (current_dir); 7 external calls (Char, new, new, assert!, assert_snapshot!, empty, vec!).

fn app_server_exec_approval_request_splits_shell_wrapped_command()

Purpose: This test checks that a command sent by the app server as one shell-quoted string is turned back into separate command arguments. That matters because the UI and approval logic need to know the actual executable, shell flag, and script text instead of treating the whole line as one blob.

Data flow: It builds a shell-wrapped command string, like /bin/zsh -lc 'python3 -c ...', using shell quoting that can safely round-trip. That string goes into the app-server approval conversion function. The resulting internal request should contain a vector of three parts: the shell path, the -lc flag, and the script itself.

Call relations: The normal test runner calls this unit test. It uses shell-joining support to create realistic input, then uses a direct equality check to verify that the conversion step produces the command shape that later approval UI code expects.

Call graph: 2 external calls (assert_eq!, try_join).

fn app_server_exec_approval_request_preserves_permissions_context()

Purpose: This test makes sure an execution approval request does not drop extra permission information. It specifically checks both network context and requested file-system access.

Data flow: It starts with absolute read and write paths, converts them into the API’s path-string form, and puts them into a fake app-server command approval request. The conversion function turns that API request into the internal approval request. The test then checks that the network host/protocol and the additional file-system permissions are still present and unchanged.

Call relations: The test runner calls this test as part of the approval-request suite. The test uses path conversion helpers to mimic real app-server data, then hands the request through the same conversion path used before the chat widget displays or processes an approval.

Call graph: calls 2 internal fn (try_from, from_abs_path); 3 external calls (from, assert_eq!, vec!).

async fn network_exec_approval_history_describes_session_host_allowance()

Purpose: This test checks the history text for a network approval that is accepted for the whole session. It ensures the user record says that a host was allowed beyond just a single request.

Data flow: It creates a chat widget and a fake approval request for HTTPS access to example.com, with available choices including accept-for-session and cancel. The request is shown to the widget, the test simulates pressing a, then it reads the produced history entry. A snapshot verifies the final wording.

Call relations: The async test runner invokes this scenario. The test feeds a network approval request into the chat widget, simulates the user choosing the session-wide allowance shortcut, and then uses snapshot checking to protect the history message that the rest of the UI will show.

Call graph: 4 external calls (Char, new, assert_snapshot!, vec!).

async fn network_exec_approval_history_describes_one_time_host_allowance()

Purpose: This test checks the history text for a network approval accepted only once. It makes sure a temporary allowance is not described as a broader session permission.

Data flow: It builds a fake network approval for HTTP access to example.com, without a command string, and gives the user choices to accept or cancel. After the widget receives the request, the test simulates pressing y. It then pulls the resulting history entry and compares its text to the saved snapshot.

Call relations: The async test runner calls this test. The test follows the same path a real one-time approval would follow through the widget: request arrives, user presses the approval key, and the history output is checked for clear wording.

Call graph: 4 external calls (Char, new, assert_snapshot!, vec!).

async fn network_exec_approval_history_describes_canceled_host_request()

Purpose: This test checks the history text when the user denies a network approval request. It confirms that a canceled request is recorded clearly instead of looking like it was allowed.

Data flow: It creates a fake request for SOCKS5 TCP access to example.com, including a command-like network access string and choices to accept or cancel. The widget receives the request, the test simulates pressing n, and the emitted history entry is read. A snapshot confirms the canceled-host wording.

Call relations: The async test runner runs this case with the other network approval tests. It drives the chat widget through the denial path and then uses snapshot checking to make sure the visible record of the decision remains accurate.

Call graph: 4 external calls (Char, new, assert_snapshot!, vec!).

fn app_server_request_permissions_preserves_file_system_permissions()

Purpose: This test checks conversion of a general permissions request from app-server format into the app’s internal format. It makes sure network permission, read roots, write roots, the current working directory, and the remote environment id are all preserved.

Data flow: It creates absolute read, write, and working-directory paths, converts the read and write paths into the API path format, and builds a fake permission request. The conversion function returns an internal request. The test compares the result against the expected internal permission profile, current directory, and environment id.

Call relations: The test runner calls this unit test directly. The test exercises the conversion step that runs before a permissions approval reaches the UI, using equality checks to prove that important permission details are not lost or reshaped incorrectly.

Call graph: calls 2 internal fn (try_from, from_abs_path); 3 external calls (from, assert_eq!, vec!).

async fn exec_approval_uses_approval_id_when_present()

Purpose: This test makes sure the widget replies with the explicit approval id when one is provided. That matters because the approval id can identify a subcommand, while the call id may identify a larger parent operation.

Data flow: It creates a command approval request whose call_id and approval_id are different. After passing the request into the chat widget, the test simulates pressing y. It then reads outgoing app events until it finds the execution approval operation, and checks that the id is approval-subcommand and the decision is accept.

Call relations: The async test runner invokes this test. The test drives the same path used when a user approves a command, then inspects the outgoing operation that would be sent back to the rest of the application.

Call graph: calls 1 internal fn (current_dir); 6 external calls (Char, new, assert!, assert_eq!, assert_matches!, vec!).

async fn exec_approval_decision_truncates_multiline_and_long_commands()

Purpose: This test checks that final approval history stays readable when commands are multi-line or very long. The approval modal may show useful detail, but the later chat history should summarize without flooding the screen.

Data flow: First it sends a multi-line shell command into the widget and confirms no history entry is written before the user decides. It renders the modal and checks that the first line of the command is visible, then simulates pressing n and snapshot-checks the aborted decision history. Next it builds a very long command, sends another approval request, confirms no early history entry appears, rejects it, and snapshot-checks the shortened history text.

Call relations: The async test runner calls this longer scenario. The test uses current-directory data, simulated key events, an in-memory render buffer, string formatting for the long command, assertions, and snapshots to cover both the display step and the post-decision history step.

Call graph: calls 1 internal fn (current_dir); 9 external calls (Char, new, new, new, assert!, assert_snapshot!, format!, empty, vec!).

async fn submission_preserves_text_elements_and_local_images()

Purpose: Checks that sending a message with a local image keeps both the visible placeholder text and the hidden image file path. This matters because the user sees a label like “[Image #1]”, while the backend needs the real image path.

Data flow: The test starts with a fresh chat widget and a configured thread session. It puts text, a text element marking the image placeholder, and a local image path into the composer, then presses Enter. The outgoing user turn contains the local image followed by the text, and the displayed history cell stores the same text, text element, and local image path.

Call relations: The Tokio test runner calls this as an isolated async test. It drives the chat widget through session setup and key handling, then reads the outbound operation channel and app event channel to confirm submission and history display agree.

Call graph: calls 2 internal fn (read_only, new); 9 external calls (new, new, default, new, assert!, assert_eq!, format!, panic!, vec!).

async fn submission_includes_configured_active_permission_profile()

Purpose: Verifies that a submitted user turn carries the currently selected permission profile when one is present. This prevents the backend from accidentally using a default or stale sandbox setting.

Data flow: The test creates a session with a managed permission profile and an active profile named “custom”. After entering text and pressing Enter, it reads the submitted user turn. The active permission profile in that operation matches the configured one.

Call relations: The async test is run by the Tokio test harness. It prepares session state, asks ChatWidget to submit through normal key handling, and checks the operation sent toward the backend.

Call graph: calls 2 internal fn (new, new); 7 external calls (new, new, default, new, assert_eq!, panic!, vec!).

async fn submission_omits_active_permission_profile_for_legacy_snapshot()

Purpose: Checks backward-compatible behavior for old session snapshots that do not name an active permission profile. The submission should not invent one.

Data flow: The test configures a thread with a permission profile but no active profile field. It submits a simple message. The resulting user turn has no active permission profile attached.

Call relations: The test harness invokes this test directly. It exercises the same submit path as normal typing, then inspects the outbound operation to make sure legacy state is preserved as legacy state.

Call graph: calls 1 internal fn (new); 6 external calls (new, new, default, new, assert_eq!, panic!).

async fn submission_with_remote_and_local_images_keeps_local_placeholder_numbering()

Purpose: Checks that remote images and local images can be submitted together without renumbering the local image placeholder in the text. This avoids changing what the user typed just because a remote image was attached first.

Data flow: The test adds one remote image URL to the chat, then sets composer text containing “[Image #2]” for a local image. After Enter, the outgoing items contain the remote image, the local image, and the text with its original text element. The history cell also keeps the same text, local image path, and remote URL.

Call relations: The Tokio test runner runs this case. It uses ChatWidget’s remote-image state, composer state, and submission path, then compares both backend-facing data and UI history data.

Call graph: calls 2 internal fn (read_only, new); 8 external calls (new, new, default, new, assert_eq!, format!, panic!, vec!).

async fn enter_with_only_remote_images_submits_user_turn()

Purpose: Verifies that pressing Enter can submit remote images even when the text composer is empty. This lets users send an image-only prompt from a URL.

Data flow: The test configures a thread, stores one remote image URL, and leaves the composer text empty. Pressing Enter produces a user turn containing just that remote image, clears the stored remote image list, and inserts a user history cell with an empty message and the URL.

Call relations: The async test is invoked by the Tokio harness. It checks the chat widget’s normal Enter handling and verifies both the outbound operation and the history event.

Call graph: calls 2 internal fn (read_only, new); 8 external calls (new, new, default, new, assert!, assert_eq!, panic!, vec!).

async fn shift_enter_with_only_remote_images_does_not_submit_user_turn()

Purpose: Ensures Shift+Enter does not submit an image-only message. Shift+Enter is treated differently from Enter, so it should not accidentally send work.

Data flow: The test sets a remote image URL and an empty composer. It sends a Shift+Enter key event. No user turn is emitted, and the remote image URL remains attached.

Call relations: The test harness runs this as an async UI behavior check. It drives key handling and uses the outbound operation channel only to confirm nothing was submitted.

Call graph: calls 2 internal fn (read_only, new); 6 external calls (new, new, default, new, assert_eq!, vec!).

async fn enter_with_only_remote_images_does_not_submit_when_modal_is_active()

Purpose: Checks that Enter does not submit remote images while a modal popup is open. A modal is a focused dialog, so Enter should belong to that dialog rather than the composer.

Data flow: The test attaches a remote image, opens the review popup, and presses Enter. The image URL remains in chat state, and no submission operation is sent.

Call relations: The Tokio test runner calls this test. It combines modal state with normal key handling to ensure the composer does not steal keys from an active popup.

Call graph: calls 2 internal fn (read_only, new); 6 external calls (new, new, default, new, assert_eq!, vec!).

async fn enter_with_only_remote_images_does_not_submit_when_input_disabled()

Purpose: Verifies that image-only submission is blocked when composer input is disabled. This prevents sending new user work while the interface says input is unavailable.

Data flow: The test attaches a remote image, disables composer input with a message, and presses Enter. The remote image stays attached and no outbound user turn appears.

Call relations: The async test runs through the usual ChatWidget key path. It relies on the operation receiver to prove that disabled input truly blocks submission.

Call graph: calls 2 internal fn (read_only, new); 6 external calls (new, new, default, new, assert_eq!, vec!).

async fn submission_prefers_selected_duplicate_skill_path()

Purpose: Checks that when two skills share the same display name, the selected binding path wins. This matters because “figma” could refer to a repository skill or a user skill.

Data flow: The test loads two skill records with the same name but different paths. It submits text containing a bound $figma mention pointing to the user skill path. The outgoing user turn includes a skill item for the selected user path only.

Call relations: The Tokio test harness runs this case. It sets up skill metadata, submits through the composer, and inspects the backend-facing user input items.

Call graph: calls 2 internal fn (read_only, new); 7 external calls (new, new, default, new, assert_eq!, panic!, vec!).

async fn blocked_image_restore_preserves_mention_bindings()

Purpose: Checks that when an image submission is blocked and restored to the composer, mention bindings are not lost. The user should be able to fix or resubmit without reselecting mentions.

Data flow: The test gives ChatWidget text containing an image placeholder and a $file mention, plus a local image attachment and mention binding. Restore puts the same text back into the composer, rebuilds text elements for the image and mention, keeps the local image path, keeps the mention binding, and emits a warning that images are unsupported.

Call relations: The async test is driven by the test harness. It calls the blocked-image restore path directly, then checks composer state and the app-event history/warning output.

Call graph: 5 external calls (new, assert!, assert_eq!, format!, vec!).

async fn blocked_image_restore_with_remote_images_keeps_local_placeholder_mapping()

Purpose: Verifies that restoring a blocked image message keeps local image labels matched to the right files even when remote images are also present. This prevents the visible placeholder numbers from drifting.

Data flow: The test builds text with two local image placeholders numbered after an existing remote image, plus two local attachments and one remote URL. After restore, the composer text, text elements, local image attachment objects, and remote URLs are exactly the same as before.

Call relations: The Tokio test harness runs this focused restore test. It calls ChatWidget’s blocked-image restore method and inspects the resulting composer and remote-image state.

Call graph: 4 external calls (new, assert_eq!, format!, vec!).

async fn queued_restore_with_remote_images_keeps_local_placeholder_mapping()

Purpose: Checks that restoring a queued user message also preserves local image placeholder mapping when remote images exist. Queued drafts should return to the composer exactly as the user prepared them.

Data flow: The test creates a queued-style user message with two local image placeholders, two local attachments, and a remote URL. Restoring it to the composer keeps the text, places the cursor at the end, preserves text elements and local attachments, and restores the remote URL list.

Call relations: The async test is called by the Tokio test runner. It exercises the general user-message restore path rather than the blocked-image path.

Call graph: 4 external calls (new, assert_eq!, format!, vec!).

async fn interrupted_turn_restore_keeps_active_mode_for_resubmission()

Purpose: Verifies that if a turn is interrupted and a queued message is restored, the active collaboration mode remains selected for resubmission. The user should not lose the mode they were working in.

Data flow: The test enables collaboration modes, selects the planning mode, starts a task, queues a message, and simulates interruption. The queued message moves into the composer, the queue is emptied, and the active mode stays selected. When Enter is pressed again, the submitted user turn carries that same mode.

Call relations: The Tokio harness runs this scenario. It combines task lifecycle helpers, collaboration mode selection, queue restoration, and final submission to check the full interrupted-resubmit flow.

Call graph: calls 2 internal fn (new, plan_mask); 5 external calls (from, new, assert!, assert_eq!, panic!).

async fn remap_placeholders_uses_attachment_labels()

Purpose: Checks that placeholder remapping uses the labels stored on image attachments, not just their order in the text. This is important when placeholders appear in a different order than the attachment list.

Data flow: The test creates text where “[Image #2]” appears before “[Image #1]”, with attachments carrying their original labels. Remapping starts at label 3, rewrites the text to new labels, updates text element ranges and placeholder strings, updates attachment placeholder labels, and leaves remote URLs unchanged.

Call relations: The test runner calls this unit-style async test. It directly exercises remap_placeholders_for_message, a helper used when restored or combined messages need fresh image numbers.

Call graph: 4 external calls (new, assert_eq!, format!, vec!).

async fn remap_placeholders_uses_byte_ranges_when_placeholder_missing()

Purpose: Checks the fallback path for remapping image placeholders when text elements do not carry placeholder strings. The byte ranges still let the code find and replace the right visible text.

Data flow: The test supplies text elements with ranges but no stored placeholder value. Remapping reads the old placeholder text from those ranges, assigns new labels, rewrites the message text, fills in placeholder values on the text elements, and updates local image attachments.

Call relations: The Tokio test harness runs this targeted helper test. It calls the placeholder-remapping function directly to verify it works with older or incomplete text-element data.

Call graph: 4 external calls (new, assert_eq!, format!, vec!).

async fn empty_enter_during_task_does_not_queue()

Purpose: Ensures pressing Enter with an empty composer during a running task does not add an empty message to the queue. This keeps the pending queue free of meaningless entries.

Data flow: The test marks the bottom pane as task-running and leaves the composer empty. It presses Enter. The queued user message list remains empty.

Call relations: The async test is invoked by the Tokio harness. It uses the normal key handling path and inspects the input queue afterward.

Call graph: 2 external calls (new, assert!).

async fn output_free_interrupted_turn_requests_prompt_restore()

Purpose: Checks that cancelling a turn with no visible output asks to restore the original prompt. This supports an edit-and-resubmit workflow when the assistant has not really started answering.

Data flow: The test records a candidate prompt for restoration, marks a turn as started, sends an interrupt command that requests restore-if-no-output, and then simulates interruption. The outbound operation is an interrupt with that behavior, and the app event restores the cancelled prompt.

Call relations: The Tokio test runner executes this flow. It connects ChatWidget’s cancel-edit bookkeeping, command submission, and turn-interruption handling.

Call graph: calls 1 internal fn (from); 2 external calls (assert_matches!, interrupt_and_restore_prompt_if_no_output).

async fn visible_output_prevents_cancelled_turn_prompt_restore()

Purpose: Verifies that once the assistant has produced visible output, cancelling does not restore the old prompt. At that point, restoring the prompt could be confusing because the turn visibly progressed.

Data flow: The test records a restore candidate, starts a turn, feeds in visible assistant text, submits the restore-if-no-output interrupt, and interrupts the turn. It drains app events and confirms none restore the cancelled prompt.

Call relations: The async test is run by the Tokio harness. It exercises the output-tracking part of interruption handling.

Call graph: calls 1 internal fn (from); 2 external calls (assert!, interrupt_and_restore_prompt_if_no_output).

async fn thinking_status_keeps_cancelled_turn_prompt_restore_eligible()

Purpose: Checks that internal reasoning or “thinking” text does not count as visible answer output for prompt restoration. A user can still get their prompt back if only thinking status appeared.

Data flow: The test records a prompt, starts a turn, adds reasoning text, submits the restore-if-no-output interrupt, and interrupts. The app event restores the original prompt.

Call relations: The Tokio test harness runs this scenario. It separates reasoning-status updates from user-visible assistant message output in the cancel-restore flow.

Call graph: calls 1 internal fn (from); 2 external calls (assert_matches!, interrupt_and_restore_prompt_if_no_output).

async fn patch_activity_prevents_cancelled_turn_prompt_restore()

Purpose: Verifies that file patch activity counts as meaningful turn output and prevents prompt restoration. If the assistant started changing files, restoring the prompt as if nothing happened would be misleading.

Data flow: The test records a restore candidate, starts a turn, reports patch-apply activity, submits an interrupt, and simulates interruption. It drains app events and confirms no restore event is emitted.

Call relations: The async test is called by the Tokio harness. It checks that patch lifecycle events feed into the same no-output decision used by cancellation.

Call graph: calls 1 internal fn (from); 3 external calls (new, assert!, interrupt_and_restore_prompt_if_no_output).

async fn pending_steer_esc_does_not_steal_vim_insert_escape()

Purpose: Checks that Escape first exits Vim insert mode instead of interrupting a running task with pending steer messages. A steer is a follow-up instruction queued while the assistant is working.

Data flow: The test marks a task as running, adds a pending steer, enables Vim mode, enters insert mode, and presses Escape. The first Escape exits insert mode, leaves the steer queued, and sends no interrupt. A second Escape then sends an interrupt and marks pending steers for submission after interruption.

Call relations: The Tokio test runner executes this keyboard-priority scenario. It combines Vim-mode handling, pending-steer queue state, and interrupt operation emission.

Call graph: 5 external calls (Char, new, assert!, assert_eq!, panic!).

async fn pending_steer_interrupt_uses_remapped_binding()

Purpose: Verifies that pending-steer interruption honors a custom key binding instead of always using Escape. This lets users remap the interrupt key safely.

Data flow: The test changes the interrupt key to F12, starts a task, and adds a pending steer. Pressing Escape does nothing. Pressing F12 sends an interrupt and marks pending steers to be submitted after the interrupt completes.

Call relations: The async test is invoked by the Tokio harness. It exercises runtime keymap configuration, bottom-pane key binding setup, and ChatWidget key handling.

Call graph: calls 1 internal fn (defaults); 5 external calls (F, new, assert!, panic!, vec!).

async fn restore_thread_input_state_syncs_sleep_inhibitor_state()

Purpose: Checks that restoring saved input state also restores whether the app should keep the computer awake during a running turn. The sleep inhibitor is a guard that prevents idle sleep while work is active.

Data flow: The test enables the prevent-idle-sleep feature and restores state saying a task and agent turn are running. ChatWidget marks the turn as running, the sleep inhibitor reports running, and the bottom pane shows task-running. Restoring no input state clears all three.

Call relations: The Tokio test harness runs this state-restore check. It connects saved thread input state with turn lifecycle state and visible bottom-pane task state.

Call graph: 2 external calls (new, assert!).

async fn alt_up_edits_most_recent_queued_message()

Purpose: Verifies that the configured edit-queued-message shortcut pulls the newest queued message back into the composer. This lets a user fix the last pending prompt before it is sent.

Data flow: The test binds edit to Alt+Up, marks a task as running, queues two messages, and presses Alt+Up. The composer now contains the second, most recent queued message, while the queue keeps only the older first message.

Call relations: The async test is run by the Tokio harness. It checks the interaction between key binding setup, pending-input preview, queue mutation, and composer restoration.

Call graph: calls 2 internal fn (from, alt); 3 external calls (new, assert_eq!, vec!).

async fn unbound_queued_message_edit_does_not_fall_back_to_alt_up()

Purpose: Ensures Alt+Up does not edit queued messages when the edit shortcut is deliberately unbound. This respects user or terminal configuration that removes the shortcut.

Data flow: The test clears the edit-queued-message binding, starts a running-task state, and queues one message. Pressing Alt+Up leaves the composer empty and keeps the queued message in place.

Call relations: The Tokio test harness calls this case. It verifies that ChatWidget uses the configured keymap rather than a hard-coded fallback.

Call graph: calls 1 internal fn (from); 4 external calls (new, new, assert!, assert_eq!).

async fn shift_left_edits_most_recent_queued_message_in_apple_terminal()

Purpose: Checks that Apple Terminal uses Shift+Left as the queued-message edit shortcut. Some terminals report keys differently, so the default shortcut is adapted.

Data flow: The test passes Apple Terminal information to a shared assertion helper. That helper sets up queued messages, presses the expected shortcut, and confirms the newest queued message moves into the composer.

Call relations: The Tokio harness runs this terminal-specific wrapper. It delegates the real behavior check to assert_shift_left_edits_most_recent_queued_message_for_terminal.

async fn shift_left_edits_most_recent_queued_message_in_warp_terminal()

Purpose: Checks that Warp Terminal uses Shift+Left for editing the most recent queued message. This protects the shortcut behavior on a terminal with special key handling.

Data flow: The test provides Warp Terminal metadata to the shared queued-message edit assertion. The helper verifies that the shortcut recalls the newest queued message and removes it from the queue.

Call relations: The Tokio test runner invokes this wrapper. It reuses the common terminal shortcut test helper for Warp-specific terminal detection.

async fn shift_left_edits_most_recent_queued_message_in_vscode_terminal()

Purpose: Verifies that the integrated VS Code terminal uses Shift+Left for queued-message editing. This keeps the shortcut usable inside VS Code.

Data flow: The test supplies VS Code terminal information to the shared helper. The helper performs the queue setup and confirms Shift+Left edits the newest queued message.

Call relations: The async test is run by the Tokio harness. It delegates to the common terminal behavior helper with VS Code terminal metadata.

async fn shift_left_edits_most_recent_queued_message_in_tmux()

Purpose: Checks that sessions running inside tmux use Shift+Left for editing queued messages. tmux can alter key sequences, so it receives special handling.

Data flow: The test describes a terminal running under tmux and calls the shared assertion helper. The helper confirms the shortcut restores the newest queued message into the composer.

Call relations: The Tokio harness invokes this wrapper. It tests the tmux branch of terminal-aware queued-message edit behavior through a common helper.

fn queued_message_edit_binding_mapping_covers_special_terminals_and_tmux()

Purpose: Verifies the mapping from terminal type to queued-message edit shortcut. It makes sure known special terminals and tmux use Shift+Left, while ordinary iTerm2 keeps Alt+Up.

Data flow: The test feeds several terminal descriptions into the binding-selection function. Each result is compared with the expected key hint for that terminal environment.

Call relations: The standard Rust test runner calls this synchronous unit test. It directly checks the shortcut-mapping helper used when configuring the chat UI.

Call graph: 1 external calls (assert_eq!).

async fn enqueueing_history_prompt_multiple_times_is_stable()

Purpose: Checks that repeatedly recalling a prompt from history and queueing it produces identical queued messages each time. This prevents subtle mutation of history text across repeated use.

Data flow: The test submits “repeat me” once to seed history, marks a task as running, then three times presses Up to recall the prompt and Tab to queue it. The queue ends with three messages, all exactly “repeat me”.

Call relations: The Tokio test harness runs this workflow. It links history recall, task-running queue behavior, and repeated submission stability.

Call graph: calls 1 internal fn (new); 3 external calls (new, new, assert_eq!).

async fn submit_user_message_ignores_inaccessible_app_mentions_from_bindings()

Purpose: Verifies that a bound app mention is not sent as a special mention item when the app is not accessible. The raw text remains, but the backend is not told to use an app the user cannot access.

Data flow: The test enables apps, loads a connector marked enabled but inaccessible, and submits a message whose binding points at that app. The outgoing user turn contains only a plain text item with $arabica-uae, not a separate mention item.

Call relations: The async test is run by the Tokio harness. It combines connector loading, authentication/config state, and direct user-message submission.

Call graph: calls 1 internal fn (new); 4 external calls (new, assert_eq!, panic!, vec!).

fn user_message_display_from_inputs_matches_flattened_user_message_shape()

Purpose: Checks that display data built from mixed user input items matches the display data built from already-flattened message parts. This keeps history rendering consistent no matter how the message was assembled.

Data flow: The test builds inputs containing text, a remote image, a local image, a skill, an app mention, and more text. The display conversion joins only the visible text, shifts text-element ranges into the joined text, collects image paths and URLs, and matches the equivalent direct display construction.

Call relations: The standard test runner calls this synchronous test. It directly exercises ChatWidget::user_message_display_from_inputs, which is used to render submitted user messages.

Call graph: 4 external calls (from, assert_eq!, user_message_display_from_inputs, vec!).

fn user_message_display_from_inputs_hides_prompt_context()

Purpose: Verifies that hidden IDE prompt context is removed from the message shown in chat history. The user should see their actual request, not the internal context block prepended for the assistant.

Data flow: The test creates a text input with an IDE context header and a final request containing $figma. Display conversion strips the context, keeps “Ask $figma”, and adjusts the mention text element to the new range.

Call relations: The synchronous test is run by the Rust test runner. It targets the display conversion helper for messages that include hidden context.

Call graph: 3 external calls (assert_eq!, user_message_display_from_inputs, vec!).

async fn committed_user_message_with_hidden_prompt_context_renders_local_images()

Purpose: Checks that when hidden prompt context is stripped from a committed user message, local images are still shown. Removing text context must not discard image attachments.

Data flow: The test completes a user message made of hidden context text plus one local image input. The inserted user history cell has an empty visible message but still contains the local image path.

Call relations: The Tokio test harness runs this async history-rendering check. It uses the message completion helper and reads app events to inspect the resulting UserHistoryCell.

Call graph: 3 external calls (from, assert_eq!, vec!).

async fn interrupt_restores_queued_messages_into_composer()

Purpose: Verifies that interrupting a running turn moves queued messages back into the composer instead of submitting them automatically. This gives the user control after an interruption.

Data flow: The test marks a task as running, queues two messages, refreshes the pending preview, and simulates turn interruption. The composer contains both queued messages joined with newlines, the queue is empty, and no outbound user operation is sent.

Call relations: The Tokio test runner executes this interruption scenario. It checks the queue restoration path triggered by handle_turn_interrupted.

Call graph: calls 1 internal fn (from); 2 external calls (assert!, assert_eq!).

async fn interrupt_prepends_queued_messages_before_existing_composer_text()

Purpose: Checks that interrupted queued messages are restored before any draft already in the composer. This preserves the order in which the user intended messages to be handled.

Data flow: The test starts with “current draft” in the composer, queues two earlier messages during a running task, and simulates interruption. The composer becomes “first queued”, then “second queued”, then “current draft”, separated by newlines; the queue is cleared and nothing is submitted.

Call relations: The async test is called by the Tokio harness. It exercises the same interruption restore path as the previous test, but with pre-existing composer text included.

Call graph: calls 1 internal fn (from); 3 external calls (new, assert!, assert_eq!).

async fn exec_approval_emits_proposed_command_and_decision_history()

Purpose: Checks that a command approval request appears in the approval modal, not immediately in the chat history, and that approving it later adds a short decision line.

Data flow: It creates a fake chat widget, sends in an approval request for echo hello world, renders the widget, presses y, then reads the outgoing history cells. The expected result is no history entry before the decision, a modal showing the command, and one concise approval record afterward.

Call relations: This test drives the approval flow from the outside by calling the same approval handler and key-event path a real user would trigger. It then uses rendering and history-draining helpers to verify what the rest of the app would see.

Call graph: calls 1 internal fn (current_dir); 7 external calls (Char, new, new, assert!, assert_chatwidget_snapshot!, empty, vec!).

fn app_server_exec_approval_request_splits_shell_wrapped_command()

Purpose: Verifies that a shell-wrapped command string from the app server is split back into the original command parts correctly.

Data flow: It builds a request whose command is a joined shell string, converts it into an internal approval request, and checks that the resulting command vector contains the shell, option, and script as separate pieces.

Call relations: This test focuses on the conversion helper used before approval UI is shown. It protects later approval rendering from receiving one confusing blob when it needs separate command arguments.

Call graph: 2 external calls (assert_eq!, try_join).