Session-log and plugin-inventory upload apply to custom DEEPSEEK_BASE_URL endpoints

[foxj77]

Hi, I'm evaluating DSH as an embedded runtime: one ACP subprocess per agent, model traffic through a gateway set with DEEPSEEK_BASE_URL.

With the shipped acp profile at 0.2.1-alpha.5, every Messages request body includes dsh_session_log and dsh_plugin_packages. The session-log-deepseek and plugin-package-inventory-deepseek READMEs describe these as being for official DeepSeek API requests. In practice they're keyed to the deepseek-official provider rather than the endpoint, so they're still sent when the base URL points somewhere else.

To reproduce

1. DEEPSEEK_BASE_URL=http://127.0.0.1:<port> pointing at any server that logs request bodies, DEEPSEEK_API_KEY=x, DSH_TELEMETRY_DISABLED=1.
2. dsh --profile acp, then initialize, session/new and one session/prompt.
3. Top-level keys of the request body: dsh_plugin_packages, dsh_session_log, max_tokens, messages, model, output_config, stream, system, thinking, tools. On the first call dsh_session_log was ~25 KB: system prompt, user message, runtime context, and request header including tool definitions.

This overlay removes both fields, and the conversation still works:

- id: session-log-deepseek
  config: { enabled: false }
- id: plugin-package-inventory-deepseek
  config: { enabled: false }

Suggestion

The opt-out works. The ask is about the default for embedders:

• send these fields only when the request goes to the official endpoint, or when it's explicitly enabled; or
• an environment switch, similar to DSH_TELEMETRY_DISABLED, for deployments that can't ship a profile overlay; and
• a note in the README that they apply to custom base URLs too.

Context: Anthropic-compatible gateways may reject unknown top-level fields, and operators routing through their own gateway may not expect session-log content in request bodies.

Thanks for the detailed READMEs, which made this easy to track down.