messages

Maps each non-normal mode to its display glyph shown in the prompt/UI.

Reverse lookup: trigger character -> mode name.

Pattern to detect email-like text preceding an @ symbol.

If the character immediately before @ matches this pattern, the @mention is likely part of an email address (e.g., user@example.com) rather than a file reference.

Pattern for highlighting @mentions and /commands in rendered user messages.

Matches either:

• Slash commands at the start of the string (e.g., /help)
• @file mentions anywhere in the text (e.g., @README.md)

Note: The ^ anchor matches start of string, not start of line. The consumer in UserMessage.compose() additionally checks start == 0 before styling slash commands, so a / mid-string is not highlighted.

Get the glyph set for the current charset mode.

Check whether the terminal is in ASCII charset mode.

Convenience wrapper so widgets can branch on charset without importing both _detect_charset_mode and CharsetMode.

Format a duration in seconds into a human-readable string.

Format tool calls for display with tool-specific smart formatting.

Shows the most relevant information for each tool type rather than all arguments.

Open the URL from a Rich link style on click, if present.

Rich Style(link=...) embeds OSC 8 terminal hyperlinks, but Textual's mouse capture intercepts normal clicks before the terminal can act on them. By handling the Textual click event directly we open the URL with a single click, matching the behavior of links in the Markdown widget.

URLs that fail the safety check (e.g. containing hidden Unicode or homograph domains) are blocked and not opened; the event bubbles and a warning is logged and displayed as a Textual notification.

On success the event is stopped so it does not bubble further. On failure (e.g. no browser available in a headless environment) the error is logged at debug level and the event bubbles normally.

Yield per-line Static widgets for a unified diff.

Each added/removed line gets a CSS class (.diff-line-added, .diff-line-removed) so background colors are driven by CSS variables and update automatically on theme change.

Result of formatting tool output for display.

Widget displaying a user message.

Widget displaying a queued (pending) user message in grey.

This is an ephemeral widget that gets removed when the message is dequeued.

Widget displaying a skill invocation with collapsible body.

Shows skill name, source badge, description, and user args as a compact header. The full SKILL.md body (frontmatter stripped) is hidden behind a preview/expand toggle (click or Ctrl+O). The expanded view renders markdown via Rich's Markdown inside a single Static widget.

Visibility is driven by a CSS class (-expanded) toggled via a Textual reactive var. Click handlers are scoped to the header and hint widgets (_SkillToggle) so clicks on the rendered markdown body do not trigger expansion toggles (preserving text selection, for instance).

Widget displaying an assistant message with markdown support.

Uses MarkdownStream for smoother streaming instead of re-rendering the full content on each update.

Widget displaying a tool call with collapsible output.

Tool outputs are shown as a 3-line preview by default. Press Ctrl+O to expand/collapse the full output. Shows an animated "Running..." indicator while the tool is executing.

Widget displaying a diff with syntax highlighting.

Widget displaying an error message.

Widget displaying an app message.

Widget displaying a summarization completion notification.

LangChain brand colors and semantic constants for the CLI.

Single source of truth for color values used in Python code (Rich markup, Content.styled, Content.from_markup). CSS-side styling should reference Textual CSS variables: built-in variables ($primary, $background, $text-muted, $error-muted, etc.) are set via register_theme() in DeepAgentsApp.__init__, while the few app-specific variables ($mode-bash, $mode-command, $skill, $skill-hover, $tool, $tool-hover) are backed by these constants via App.get_theme_variable_defaults().

Code that needs custom CSS variable values should call get_css_variable_defaults(dark=...). For the full semantic color palette, look up the ThemeColors instance via ThemeEntry.REGISTRY.

Users can define custom themes in ~/.deepagents/config.toml under [themes.<name>] sections. Each new theme section must include label (str); dark (bool) defaults to False if omitted (set to True for dark themes). Color fields are optional and fall back to the built-in dark/light palette based on the dark flag. Sections whose name matches a built-in theme override its colors without replacing it. See _load_user_themes() for details.