feat(logging): add network.log for main and renderer requests

[charlesvien]

Problem

Diagnosing API failures, gateway timeouts and flaky endpoints from user logs is impossible today. main.log captures app logs and chromium.log captures native Chromium output, but there is no persistent record of the network requests the main and renderer processes make or how they fail.

Changes

• New always-on network.log next to main.log and chromium.log in ~/.posthog-code/{logs,logs-dev}/, with the same 10MB ring rotation (network.1.log..network.3.log). The rotation helper is extracted and shared with main.log so the policies cannot drift.
• Main process: a globalThis.fetch wrapper records every request (method, redacted URL, status or error, duration, content-length). Installed before app.whenReady() so it sits under the dev toolbar's DevNetworkService wrapper and survives dev mode toggling. Covers authenticatedFetch, the LLM gateway legs of auth-proxy and mcp-proxy, S3 log fetches and GitHub release downloads.
• Renderer: session.webRequest observers on the persist:main partition capture all renderer traffic (fetch, XHR, sendBeacon from posthog-js) with zero renderer code changes. The onBeforeRequest callback is invoked in a finally so a listener error can never stall requests.
• One readable line per request, log level mapped to outcome: info for 2xx/3xx, warn for 4xx, error for 5xx and network failures.

[2026-07-02 12:20:22.152] [info]  [main] GET https://github.com/PostHog/posthog/releases/download/agent-skills-latest/skills.zip -> 200 107ms 2382486B
[2026-07-02 12:20:24.416] [info]  [renderer] POST https://us.posthog.com/api/projects/2/tasks/summaries/ -> 200 290ms -
[2026-07-02 12:20:24.686] [warn]  [renderer] GET https://us.posthog.com/api/projects/2/tasks/<id>/runs/<id>/session_logs/?limit=100000 -> 400 151ms -
[2026-07-02 12:20:51.623] [error] [renderer] GET https://us.posthog.com/api/projects/2/signals/reports/?limit=1&status=ready -> ERR "net::ERR_ABORTED" 2551ms -

• Loopback traffic (workspace-server tRPC on 127.0.0.1, Vite dev server) is skipped via one obvious predicate so the file stays real-network only.
• Sensitive query param values (token, secret, code, X-Amz-Signature, ...) are redacted to ***. Headers and bodies are never logged.
• Renderer requests also mirror into the dev toolbar Network panel, filling the schema's previously never-produced renderer origin (gated behind dev mode as before).
• The startup banner now includes the network.log path.

Known blind spots (documented, unchanged): the workspace-server child process's own connectivity probes, git/gh CLI subprocess HTTPS and electron-updater's internal client. Agent CLI LLM traffic is captured via the auth-proxy outbound leg in main.

How did you test this?

• 81 new unit tests: redaction (every sensitive param, case-insensitivity, malformed URLs), loopback gate, level mapping boundaries, exact line format, fetch wrapper (success, sync throw, async rejection, string/URL/Request inputs, missing content-length, preconnect forwarding, idempotent install) and webRequest listeners (mandatory callback, completion, error, non-2xx, evicted start entries). Full apps/code suite passes (263 tests).
• pnpm --filter code typecheck, biome check on all touched files and node scripts/check-host-boundaries.mjs (no new violations) all pass.
• Ran the dev app: network.log filled with 142 lines in the first ~30s of boot (118 [main], 24 [renderer]), the banner logged network=~/.posthog-code/logs-dev/network.log, zero loopback lines while workspace-server tRPC ran underneath, a live 400 logged at warn, a real renderer net::ERR_ABORTED logged at error and nothing leaked into main.log.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

[trunk-io]

Merging to main in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[charlesvien]

• feat(logging): add network.log for main and renderer requests #3111 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[github-actions]

React Doctor found no issues in the changed files. 🎉

_{Reviewed by React Doctor for commit 322287f.}

[greptile-apps]

_{Reviews (1): Last reviewed commit: "add network.log for main and renderer re..." | Re-trigger Greptile}

[stamphog]

This PR exceeds the automated review size ceiling (979 lines, 9 files). The changes look like a well-contained logging feature, but the scope warrants a human reviewer to verify the fetch-wrapping order, session partition usage, and that network logs don't inadvertently capture sensitive tokens or credentials before redaction.

[adboio]

approving to unblock, but robot suggests considering onSendHeaders as a non-blocking observer instead of onBeforeRequest, makes sense at a glance, prob worth a peep:

Electron's onSendHeaders is the non-blocking observer equivalent: no callback, cannot delay or stall a request, and provides the same details.id for start-time tracking (plus a details.timestamp that's more accurate than Date.now() at listener invocation). The only trade-off is that disk-cache hits may skip it — and the code already handles missing start entries gracefully (takeDuration returns 0, with a test covering it). That seems strictly better than adding a main-process round-trip to every live request. onCompleted/onErrorOccurred are already non-blocking, so only the one listener changes, and the ObservableWebRequest interface actually gets simpler.

[tatoalo]

thanks 🐐