Add `excludeFromContext` to custom messages sent via `sendMessage()`

[zachmeador]

What do you want to change?

Add excludeFromContext?: boolean to CustomMessage / pi.sendMessage(), mirroring the flag that bash-execution messages already have. convertToLlm would skip flagged custom messages the same way it already skips !! bash executions.

Why?

I have a /status command that prints a status panel into the chat. Today it works by patching InteractiveMode internals, and I want it to be a plain extension command instead.

Extension commands are supposed to produce output through sendMessage(), and together with registerMessageRenderer() that gives me a persistent, custom-rendered block in chat. The problem is that every custom message is also converted into a user message for the LLM. So the status panel ends up in model context, where it is just noise.

Built-in commands like /session and /changelog can print to chat without the model seeing it. Extension commands have no way to do the same. This flag would close that gap: output persisted in the session, rendered in the TUI, skipped for LLM calls.

How? (optional)

Three small changes: the flag on CustomMessage in core/messages.ts, a skip in convertToLlm's "custom" case, and plumbing through the sendMessage signatures in core/extensions/types.ts. Same shape as #5039, which added this flag to the bash RPC command. Happy to implement it if approved.

[github-actions]

This issue was auto-closed. All issues from new contributors are auto-closed by default.

Maintainers review auto-closed issues daily and reopen worthwhile ones. Issues that do not meet the quality bar in CONTRIBUTING.md will not be reopened or receive a reply.

If a maintainer replies lgtmi on one of your issues, your future issues will stay open. If a maintainer replies lgtm, your future issues and PRs will stay open.

See CONTRIBUTING.md.

[mitsuhiko]

I think we should be doing this but I'm not yet sure if extending CustomMessage is the way here, or if we want to add a new message type instead.

I put a test implementation with just the flag on custom message onto a branch: #5678

[zachmeador]

Flag works for me: my extension sends both model-visible and excluded messages, and they share one customType renderer, which a separate type would split.

Tested the branch with that setup: excluded content never reaches the provider request body and stays excluded after resuming from disk.

[xl0]

I use the workaroud of setting content to "" and using display to show the messages. But then without the extension loaded I don't see the messages. A flag on CustomMessages wuld be ideal for me.

[mitsuhiko]

So while I want this, this actually turns out to be a much bigger change because there are quite a few code paths that make assumptions today. I will need to think a bit more about this.

[mitsuhiko]

I updated the implementation in #5678. I would welcome people to test this and give feedback.

[zachmeador]

I tested the PR branch from #5678 locally, and it covers the behavior I was asking for here.

Specifically, a custom message sent with:

sendMessage({ display: true, excludeFromContext: true, ... })

is still persisted/renderable, but is omitted from convertToLlm() provider context. I also confirmed the flag is exposed in the relevant CustomMessage and sendMessage() TypeScript surfaces.

I ran tests around custom-message persistence, queueing, retry/event ordering, compaction, and conversion, and they passed. Also did a sanity check that excluded custom message text is absent from the LLM message output while normal custom messages remain included. No visible regressions in the TUI.

From my side, this solves the need. Thank you!