Add API to configure default collapsed/expanded state of tool/reasoning details in @mui/x-chat

[flo-cursor]

Summary

Please add a public API to configure the default open/closed state of collapsible message parts in @mui/x-chat, especially:

• tool parts
• reasoning parts

Right now, the default collapse behavior appears to be hardcoded internally. For example, tool parts are auto-opened for certain states such as approval-requested and input-streaming.

It would be very helpful to support something like:

• a boolean default, e.g. defaultOpen
• or a callback, e.g. getDefaultOpen(ownerState) => boolean

either:

• globally on ChatMessageContent
• per part type in partProps
• or specifically on tool/reasoning part slots

The main goal is to let consumers control whether these collapsible parts are initially expanded or collapsed without having to fork or replace the internal implementation.

Examples

Current internal behavior seems to be implemented inside the internal collapsible root, roughly like this:

const [open, setOpen] = React.useState(
  () => state === 'approval-requested' || state === 'input-streaming',
);

React.useEffect(() => {
  if (state === 'approval-requested') {
    setOpen(true);
  }
}, [state]);

A possible API could look like one of these:

<ChatMessageContent
  partProps={{
    tool: {
      defaultOpen: false,
    },
    reasoning: {
      defaultOpen: false,
    },
  }}
/>

or

<ChatMessageContent
  partProps={{
    tool: {
      getDefaultOpen: ({ state }) => state === "approval-requested" || state === "output-error",
    },
  }}
/>

or via slot props:

<ChatMessageContent
  partProps={{
    tool: {
      slotProps: {
        root: {
          defaultOpen: false,
        },
      },
    },
  }}
/>

Motivation

I want to keep the default MUI styling and structure of tool/reasoning parts, but customize only the initial collapsed state.

A real use case:

• tool parts should stay collapsed by default
• but automatically expand for important states such as:
  • approval required
  • error states

At the moment, the only workaround seems to be overriding or forking the internal root/details implementation. That is fragile and makes it harder to stay aligned with upstream styling and behavior.

Having a supported configuration API would:

• improve flexibility
• reduce the need for internal overrides
• make upgrades easier
• support common UX patterns for chat/tool rendering

Search keywords: mui x chat collapse default state tool details reasoning details open closed ChatMessageContent ChatToolPartRoot approval-requested output-error details default open state

Order ID: 123283