In general, to fix information exposure through exceptions, never send raw exception messages or stack traces to clients. Instead, log detailed error information on the server side, and return a generic, non-sensitive message to the client. If you need user-friendly messages, base them on known-safe patterns rather than arbitrary exception text.

For this file, the best targeted fix is to modify _friendly_error so that it no longer returns text dynamically constructed from str(e) (such as interpolating token counts from a backend error message). Instead, it should inspect the message only to decide which predefined generic text to return. That way, even if the backend error message contains sensitive details, these never flow back to the client. Concretely:

• Keep using msg = str(e) and regex checks to detect specific error cases, but avoid returning m.group(1) or m.group(2) to the user.
• Replace the current context-window error string with a static, generic explanation without embedding numeric values from the backend.
• Keep the existing generic lost-connection message; it already does not reuse raw backend text.
• Keep the default fallback "An internal error occurred".

All other logic stays the same. No changes are required at the call site (the except Exception as e: block and the yield with _friendly_error(e) remain). No new imports or helper methods are needed.

In general terms, the fix is to ensure that user-facing error messages are generic and do not depend on the raw exception text. The exception (and any stack trace or detailed message) should be logged server-side only, while the client receives a high-level, non-sensitive description. Helper functions such as _friendly_error should avoid calling str(e) for arbitrary exceptions when constructing client-visible messages.

The best focused fix here is to change _friendly_error so that it only uses raw exception messages for very narrow, known-safe patterns (or not at all), and otherwise always returns a generic string without leaking str(e). In this code, _friendly_error already returns a generic "An internal error occurred" for the default case; the problematic bit is using str(e) unconditionally to do regex and substring matches. To avoid exposing arbitrary exception details while retaining functionality, we can still call str(e) internally but constrain what we return: for the context-window regex we only surface the numeric token counts (derived via regex groups), and for the connection-loss case we return a static string that does not echo the original message. We should not fall back to returning msg itself anywhere.

Concretely, in studio/backend/streaming_server.py, we keep the structure of _friendly_error but ensure it never returns raw or formatted exception messages or stack traces, only predefined strings. We do not need to touch the tool_sse function or the StreamingResponse construction; once _friendly_error is safe, the streamed JSON error notice is also safe. No new imports or helper methods are required.