DSH Python SDK log upload: disable session-log-deepseek

The DeepSeek Harness Python SDK includes a session-log contributor named session-log-deepseek; it uploads unaccepted log events with DeepSeek requests, up to 8 MiB per request. This is not OTel telemetry. sdk-minimal has no OTel by default but does include this contributor. For sensitive repositories or regulated environments, decide explicitly whether it should stay on.

DeepSeek Harness: What is uploaded and the cap

The upload target is “session log events”, not “the final answer” or “statistics”. Three points:(source)

1. Sent with DeepSeek requests — it rides the model request path, not a separate background job. Expected: a request may carry log events.
2. Only unaccepted events — the official wording is “unaccepted log events”, not the whole session. Expected: it does not resend all history every time.
3. At most 8 MiB per request — controlled by maxBytes. Expected: one request cannot carry an unbounded log.

What counts as an event depends on the session log. Conversation messages, tool calls, and tool results that enter the log may be in scope. Do not read this as “only error statistics”.

DeepSeek Harness: How to disable it

Disabling takes one profile patch: session-log-deepseek.enabled: false. Two ways:(source)

# $DSH_HOME/profiles/sdk-minimal/cordis.patch.yml
- id: session-log-deepseek
  config:
    enabled: false

1. Persistent — write it into profiles/sdk-minimal/cordis.patch.yml. Expected: every future SDK start skips upload.
2. Per run — create a separate patch file and pass it through patches=(...). Expected: only the current process is affected.
3. Restart and verify — restart the host process. Expected: the new process uses the new setting; an old process keeps the old one.

If enabled: false does not take effect, confirm you edited the profile under the dsh_home the SDK actually uses. The SDK reads only the home you pass.

DeepSeek Harness: Three log links, not one

session-log-deepseek, the local session log, and OTel are separate paths. Compare:(source)

Disabling the second does not delete the first; disabling OTel does not stop the second. When asking “did data leave the machine?”, check all three, not one switch.

DeepSeek Harness: What remains locally

Disabling upload does not disable logging. The SDK still writes local JSONL. Local data includes:(source)

• sessions — uncompressed JSONL under dsh_home/sessions, with conversations and tool results.
• profile — the sdk-minimal configuration and installed plugins.
• credentials and settings — if the home used a provider, related credentials may be present.

If the goal is “nothing local either”, handle sessions/ and clean the home after the job. Disabling upload alone is not a no-trace mode.

DeepSeek Harness: Three control levels

When one switch is not enough, control at application config, per-run patches, and the network layer. Compare:(source)

1. Application config — disable in the profile patch for long-term use. Cost: reapply after switching home or profile.
2. Per run — disable with patches for sensitive jobs. Cost: easy to forget, which silently restores the default.
3. Network layer — restrict egress domains in a container or gateway. Cost: may affect model requests themselves; rules must be precise.

The layers stack. A good default is “disabled by profile + network egress as a backstop”, not one YAML switch alone.

DeepSeek Harness: Compliance questions

Answer three questions before deciding: how sensitive is the data, does the request leave the corporate network, and does the log contain third-party content? Guidelines:(source)

1. Sensitivity — keys, customer data, or unpublished code means disable by default. Expected: log events do not leave with requests.
2. Network boundary — model requests already leave the machine; the log is additional payload. If model egress itself is not allowed, fix the network first.
3. Third-party content — tool results may include user data or web content. Expected: classify it and handle it accordingly.

For most local development, the default is not catastrophic; for regulated environments, disabling by default is safer. The important part is making an explicit choice.

How to verify upload state

Do not guess; check configuration, the effective tree, and the actual request. Steps:

1. Inspect the profile patch — is session-log-deepseek.enabled false or unset? Expected: a clear intent.
2. Dump the effective tree — dsh --profile sdk-minimal --dump-config. Expected: the patch really stacked.
3. Observe the request or egress — capture one model request in a controlled environment. Expected: evidence rather than memory.

If the three disagree, trust the actual request. Configuration that says false but traffic that still carries logs means the wrong home or profile was edited.

DeepSeek Harness FAQ

Does the model still work after disabling upload? Yes. The switch disables the log contributor, not model requests, tools, or session persistence.

Is 8 MiB per session or per request? The official wording is per request, capped by maxBytes. It is not a total session limit.

Is this the same as /feedback? No. /feedback is an explicit user action; session-log-deepseek is a default session-log contributor.

The short version: SDK log upload is a default behavior, not a statistics feature. Control it in the profile patch, and remember local sessions still exist.