Full custom component to render instead of the default shell.
Optionalname?: stringAgent name. With a custom component there is no shell header to put it in, so it becomes the page title.
Allowed here rather than never because client({ name, component }) is
the natural thing to write and two different models wrote it. As never
it failed with "Type 'string' is not assignable to type 'undefined'",
which explains nothing, and cost a build round each time. There is a real
use for the value — a custom-UI page otherwise inherits whatever title
the HTML shell shipped with — so it is honoured instead of banned.
Optionalsidebar?: neverOptionalsidebarWidth?: neverOptionaltools?: ToolDisplayConfigTool display config: icon and label overrides keyed by tool name.
Allowed here for the same reason as name above, and it was found the
same way: four starters across an eval run wrote
client({ component, tools }) and lost a build round each time to
"Type '{ … }' is not assignable to type 'undefined'".
Unlike sidebar/sidebarWidth, this is not a property of the default
shell. client() below wraps BOTH tiers in ToolConfigContext.Provider
from config.tools ?? {}, and the consumer is ToolCallBlock — which a
custom component renders as soon as it uses MessageList or ChatView,
the usual way to build one. So the value was always honoured at runtime;
only the type refused it.
Tier 2: custom component — renders the provided
componentinside the providers instead of the default shell.