logs_2.sqlite: rmcp::service TRACE rows (~1.3 MB ListToolsResult dumps) bypass the noisy-target filter — 50-68 MB/day with a large MCP catalog #34291

What happened

After the #28224 fixes landed (#29432, #29457, #29599 — big improvement, thank you), one high-volume emitter still reaches the persistent sqlite feedback log (logs_2.sqlite): target rmcp::service, level TRACE, whose bodies are full JSON-RPC PeerMessage dumps from app_server.request{...}:initialize:serve_inner — most notably complete ListToolsResult payloads. With a large MCP tool catalog (~180 tools/connectors in our deployment), each such row is ~1.28 MB.

Measurements (read-only queries against logs_2.sqlite)

• codex-cli 0.144.3, linux x86_64, app-server mode over stdio (embedded in a gateway product)
• 290 rmcp::service rows >1 MB totaling 371 MB = 49% of a 751 MB file
• 38-54 such rows/day = 50-68 MB/day sustained
• TRACE overall = 84% of estimated_bytes in the DB
• The built-in ~10-day retention bounds total size, but the write volume/WAL churn remains (this is the same SSD-endurance concern as Codex SQLite feedback logs can write ~640 TB/year and rapidly consume SSD endurance #28224)

Notes

• RUST_LOG in the parent environment does not affect the sqlite sink (consistent with Windows Codex app continuously writes high-volume TRACE websocket logs to ~/.codex/logs_2.sqlite despite RUST_LOG=warn #29463) — verified by restarting the parent with RUST_LOG=info,rmcp=warn and watching >1 MB rows continue to land.

Ask

Include rmcp::service (or rmcp*) in the persistent-log noisy-target filter introduced in #29457, and/or cap per-row payload size for the sqlite sink. A documented level/off knob for the sqlite sink would also serve (the sqlite_logs_enabled escape hatch discussed in #28224 was never merged).