Extend the existing Pi bundle-MCP Docker e2e harness so the live stdio MCP
probe also exercises `splitSdkTools` and asserts the configured server tool
reaches `customTools` for coding/messaging and is filtered out for minimal
and `tools.deny: ["bundle-mcp"]`. The harness already had real materialize
plus profile-filter coverage against a real stdio MCP child, but did not
assert the splitSdkTools().customTools boundary, which is the value the SDK
serializes to the outbound provider request body and the disputed boundary
on #76063.
Refs #76063.
Add focused regression coverage for the request boundary called out by
ClawSweeper triage on #76063: configured (`cfg.mcp.servers.<name>`) tools
must materialize, survive `applyFinalEffectiveToolPolicy`, and reach
`splitSdkTools().customTools`, which is the value the SDK sends to the
provider as `customTools`. The materialize, policy, and split units each
have their own unit tests, but the full chain was uncovered, which is why
v2026.4.27 was able to silently drop server__* tools from outbound
request bodies. Run with a fake `SessionMcpRuntime` so the test does not
boot a real stdio child:
- coding profile keeps configured `server__*` tools in customTools
- messaging profile keeps configured `server__*` tools in customTools
- minimal profile strips them
- explicit `tools.deny: ["bundle-mcp"]` strips them under coding
- materialize ordering survives the request boundary so prompt cache
keys stay stable across turns
Refs #76063.
Summary:
- Use Node's pathToFileURL for the base-config schema generator entrypoint guard so Windows backslash paths are recognized correctly.
- Keep the schema generation logic unchanged and preserve the current changelog attribution.
Verification:
- node --import tsx scripts/generate-base-config-schema.ts --check
- pnpm build
- pnpm check
- GitHub CI passed, including Real behavior proof, auto-response, ClawSweeper dispatch, and full repository checks.
Co-authored-by: Fusion future <23738961+easyteacher@users.noreply.github.com>
* fix(slack): include bot root message in new thread sessions (#79338)
When a user replies in-thread to a bot's own message in a Slack DM,
the new thread session was constructed without the parent/root message
content. The agent only saw `reply_to_id` metadata and could not
resolve what was being replied to, leading to confident-but-wrong
actions on follow-up corrections.
The thread-context resolver was filtering out every message authored
by the current bot before formatting thread history, including the
bot's own root message. For thread-replies starting a fresh session,
that left the agent without the parent context it needed.
This change retains current-bot messages in the thread history when
starting a new thread session, formats them with role=assistant under
a "Bot (this assistant)" sender label, and adds
`channels.slack.thread.includeRootMessage` (default `true`) to opt out.
Bot messages still bypass allowlist visibility filtering since the
bot's own output is not third-party content.
Fixes#79338.
* fix(slack): wire includeRootMessage into runtime config schema (#79338)
The first commit added `channels.slack.thread.includeRootMessage` to
the TypeScript type and zod schema, but the runtime AJV-style schema
generated from `extensions/slack/src/config-ui-hints.ts` rejected the
new field with `must NOT have additional properties` at gateway boot.
Adds the matching UI hint entry for `thread.includeRootMessage` and
regenerates the bundled channel config metadata so the live gateway
accepts the new field.
* Narrow Slack thread root context handling
Remove the public includeRootMessage config and keep the Slack thread fix focused on including only the current bot's root message on the first turn of a new thread session.
Preserve filtering of arbitrary current-bot Slack history while ensuring #79338 has parent/root context.
* Fix Slack thread root CI checks
---------
Co-authored-by: Bek <bek.akhmedov@gmail.com>
