Per-provider-instance opt-out for provider event logs

[excenter]

Note

🤖 Claude Sonnet 5.5 (Claude Code) writing on behalf of excenter

If you run both cloud and local providers in T3 and want the local ones to leave no plaintext copy on disk, please upvote 👍

Problem.
The server always writes logs/provider/events.<threadId>.log with decoded provider messages: prompts, replies, thinking, tool inputs and results. The only controls are the fixed retention limits (14 days, 512 MiB, in resolveOptions). I run a Claude instance against a local model (ANTHROPIC_BASE_URL=http://127.0.0.1:…). Nothing leaves the machine, yet every conversation is still written to disk in plaintext. #16490 ("option to turn off provider event logs", closed) raised the same need (agents covered by a BAA versus agents that aren't) with a server-wide flag, and was deferred pending an Ideas discussion on scope. This proposes the per-instance variant.

Why per instance rather than server-wide.
The need is almost always mixed. The #16490 motivation was some agents covered and some not. Mine is cloud providers versus a local one. A server-wide switch would force me to give up the logs for debugging the cloud providers too. ProviderInstanceConfig already carries per-instance enabled, environment and config, and each driver's create already receives its instanceId together with providerEventLoggers.

Proposal.
One optional per-instance field, off by default (logging stays on), that makes that instance's threads skip the native and canonical event loggers. It would work like T3CODE_LOG_WS_EVENTS and T3CODE_TELEMETRY_ENABLED, which already let operators opt out of a data stream. A server-wide env var in the same style would also cover #16490's case, and I'm happy to go either way.

What doesn't change.
Defaults, existing logs, retention for other instances, and the thread database. The database part is #17845, and I'm deliberately leaving it out. The provider's own transcripts (for example Claude Code's) are also out of scope; I handle those with a wrapper that passes --no-session-persistence.

Verification.
I confirmed the current behaviour from the server source (layerProviderEventLoggers returns the no-op logger only if the store fails to open) and from the log files themselves. They carry full assistant and user messages and the instance id (provider-instance:<id>:thread:…) on every line. I haven't built the change or estimated its size.

Would you accept this direction? If so, I'm happy to send a small PR, with tests that check no file is created for an opted-out instance.