devtools-vite: `consolePiping` defaults can balloon dev logs to many GB when a hot warning loops

[dsfaccini]

Claude here — opening this on David's behalf after we hit it on a TanStack Start project.

Summary

@tanstack/devtools-vite (v0.6.0) ships with consolePiping.enabled: true and levels: ['log', 'warn', 'error', 'info', 'debug'] by default. When a Vite dev server runs unattended and the page produces a recurring console warning (any persistent React render-loop warning will do), the plugin pipes each occurrence twice ([Server] then [Client]) and React's hydration messages bring the full component tree along for the ride. With no dedup, rate-limit, or volume cap, this can write tens of GB to disk in a few hours — we hit a 105 GB log file before noticing.

Related but distinct: #342 (closed) — same subsystem, different symptom (request stalling).

Reproduction

Minimal TanStack Start project. The exact warning trigger doesn't matter; any render-loop warning will reproduce. Easiest case: a hydration error from invalid HTML nesting.

vite.config.ts:

import { defineConfig } from 'vite'
import { devtools } from '@tanstack/devtools-vite'
import { tanstackStart } from '@tanstack/react-start/plugin/vite'
import viteReact from '@vitejs/plugin-react'

export default defineConfig({
  plugins: [devtools(), tanstackStart(), viteReact()],
})

A component with nested interactive elements (React 19 will warn on every render):

export default function Card() {
  return (
    <button onClick={() => {}}>
      <button onClick={(e) => e.stopPropagation()}>nested</button>
    </button>
  )
}

Start dev with output redirected to a file (typical CI / nohup setup):

nohup pnpm dev > dev.log 2>&1 &

Visit the page and leave the tab open. dev.log grows continuously. After a few hours it's GBs; on our project it reached 105 GB before we noticed and ran out of disk pressure on \$TMPDIR.

Why it explodes

Each repeat of the same warning produces:

1. A server-side log line.
2. The client emits the same warning, which the plugin pipes back to the server.
3. The server emits its piped copy back to the client.
4. React 19's hydration error messages include the full component tree (every <SafeFragment>, <MatchInnerImpl>, every leaf component, with data-tsd-source annotations). This is a large payload per occurrence.
5. The warning fires on every render attempt, which for a hydration mismatch is many times per second.

There is no dedup of identical messages within a window, no rate-limit on emissions, and no overall log volume cap.

Defaults question

consolePiping is a debug-aid feature. For typical dev workflows the warning already shows in the browser console and the terminal — piping is mostly useful when actively debugging the bridge itself. Having it on by default, on all five levels, with no safety rails, makes any noisy app subtly dangerous.

Suggested fixes (any of these would help)

1. Default consolePiping.enabled to false. Opt-in for the debug case.
2. Dedup identical messages (same level + same string content) within e.g. a 1-second window — emit once, then a [N more] summary.
3. Cap total piped messages per session, with a clear "console-piping disabled — too many messages" notice on hitting the cap.
4. Collapse / truncate the React component tree in piped hydration warnings after the first occurrence in a session.
5. (Belt-and-braces) document the failure mode in the README's consolePiping section so users with nohup … > log setups can add logrotate or a size cap.

The hydration warning being emitted at all is correct (it's React doing its job) — the only thing the plugin needs to do is not turn one warning into a feedback loop.

Environment

• @tanstack/devtools-vite 0.6.0
• @tanstack/react-start (latest at time of report)
• React 19.2.5
• Vite 8.0.10
• macOS 25.4 / Node via pnpm 10.x

Workaround

Pass consolePiping: { enabled: false } to devtools():

plugins: [
  devtools({ consolePiping: { enabled: false } }),
  // ...
],

This stopped log growth completely. We still get the actual hydration warning in the browser console (which is what we want), but no server-side amplification.

[github-actions]

Thanks for the detailed report and investigation. One required bug template field is still missing: a link to a minimal reproducible example (CodeSandbox/StackBlitz/repo). Could you share a runnable repro link so maintainers can verify and test fixes quickly?

[dsfaccini]

ahh yeah I'll have claude open a repo :)