chore(diagnostics): Instrument agent no-response failures

[charlesvien]

Problem

People intermittently get no response from the agent, transient and seemingly random, on both local and cloud tasks. The current logs don't capture the cause: undici's generic "terminated" hides the real socket reason, cloud SSE streams drop without naming the terminating hop, and local session-init failures surface only as opaque "Internal error".

Changes

1. Add serializeError to @posthog/shared to flatten an error and its .cause chain, surfacing the real undici socket reason (ECONNRESET, UND_ERR_SOCKET) behind "terminated"
2. Instrument cloud SSE streams: connect-time response headers (server, via, cf-ray, x-accel-buffering), resume detection, per-connection counters, connection durations
3. Enrich the local LLM auth-proxy: error cause, headersSent, duration, bytes streamed, plus a per-request completion baseline
4. De-opaque local agent session create/reconnect failures (real cause, code, session context) and add session-init phase timing (modelConfigMs vs initMs)
5. Surface Claude CLI stderr and a "turn completed with no agent output" warning
6. Add tests for serializeError and the proxy byte-counting

How did you test this?

Manually

Automatic notifications

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

[greptile-apps]

Comments Outside Diff (1)

1. packages/shared/src/errors.test.ts, line 573-603 (link)

   Simple input→output cases suit a parameterised test

   Several consecutive test cases each call serializeError with a single flat input and assert the full return value. Per the team's style convention these should be consolidated into an it.each table — the cases for non-Error primitives, numeric codes, bare objects, and plain Error are all the same shape ([input, expected]) and are easy to express that way. The cause-chain and cyclic-depth cases are more complex and can stay as individual it blocks.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: packages/shared/src/errors.test.ts
   Line: 573-603
   
   Comment:
   **Simple input→output cases suit a parameterised test**
   
   Several consecutive test cases each call `serializeError` with a single flat input and assert the full return value. Per the team's style convention these should be consolidated into an `it.each` table — the cases for non-Error primitives, numeric codes, bare objects, and plain `Error` are all the same shape (`[input, expected]`) and are easy to express that way. The `cause`-chain and cyclic-depth cases are more complex and can stay as individual `it` blocks.
   
   How can I resolve this? If you propose a fix, please make it concise.

   Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
packages/shared/src/errors.test.ts:573-603
**Simple input→output cases suit a parameterised test**

Several consecutive test cases each call `serializeError` with a single flat input and assert the full return value. Per the team's style convention these should be consolidated into an `it.each` table — the cases for non-Error primitives, numeric codes, bare objects, and plain `Error` are all the same shape (`[input, expected]`) and are easy to express that way. The `cause`-chain and cyclic-depth cases are more complex and can stay as individual `it` blocks.

_{Reviews (1): Last reviewed commit: "tidy error logging and add diagnostics t..." | Re-trigger Greptile}

[charlesvien]

• chore(diagnostics): Instrument agent no-response failures #2740 👈 (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 cfdc1e9.}

[stamphog]

Gates denied this PR because it touches auth-proxy code and exceeds the T2-never tier threshold. While the changes appear to be purely diagnostic logging with no behavioral modifications to auth logic, the deny-list rule exists to ensure human review of any auth-adjacent changes. With zero reviews on a multi-file change touching auth infrastructure, a human reviewer must sign off before auto-approval.

[DanielVisca]

LGTM!