fix(chat): fix /ui/chat routing, Suspense boundary, serverRootPath support

[ishaan-jaff]

Relevant issues

Follow-up to #22937 (Chat UI).

Changes

• router.push('/chat?id=...') → router.push('/ui/chat?id=...') — was redirecting to a 404
• All navigation (new chat, conversation select, new chat button) now uses getChatUrl() helper that respects serverRootPath for sub-path deployments
• Wrap chat page.tsx in <Suspense> — required by Next.js static export when useSearchParams() is used
• Fix clipboard.writeText rejection handler — was calling message.error() without importing message from antd, causing a build error

Pre-Submission checklist

• Added a test (n/a — UI routing fix)
• make test-unit passes (no Python changes)

Type

Bug fix

Test

1. Open http://localhost:4001/ui/chat
2. Select a model and send a message — URL stays at /ui/chat?id=... (not /chat?id=...)
3. Click "New chat" in sidebar — navigates correctly
4. Click a conversation in the list — navigates correctly

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
litellm	Ready	Preview, Comment	Mar 6, 2026 4:00am

[greptile-apps]

Too many files changed for review. (618 files found, 100 file limit)

In general, the fix is to perform complete escaping of n before interpolating it into the Python string literal, not just double quotes. We should escape backslashes first, then double quotes, and also normalize newlines to \n, mirroring the earlier j logic. This ensures that the generated Python code contains a valid string literal regardless of the contents of n.

Concretely, in litellm/proxy/_experimental/out/_next/static/chunks/0a55aff89c1ec2e4.js, within the case r.TRANSCRIPTION block, the template literal currently contains:

${n?`,
\tprompt="${n.replace(/"/g,'\\"')}"`:""}

We should introduce a local escaped version of n before building the template (similar to j), or inline the same escaping steps. Since we must minimize changes and preserve existing functionality, we'll keep it inline but expand the replacement chain to:

n.replace(/\\/g,"\\\\").replace(/"/g,'\\"').replace(/\n/g,"\\n")

This way, every backslash becomes \\, every double quote becomes \", and newline characters are rendered as \n in the generated Python code. No new imports or dependencies are needed; we only adjust the replace chain on line 393.

In general, when embedding arbitrary input into a string literal of another language (here: JavaScript → Python), you must correctly escape all special characters for that target string format, not just some of them. For a Python double-quoted string literal, you should at least escape \, ", and control characters like newlines and tabs. The safest option here is to reuse the escaping logic already present for inputMessage (N), which converts backslashes, double quotes, and newlines into safe escape sequences.

The best minimal fix without changing functionality is to change the l.replace(/"/g,'\\"') call at line 393 so it uses the same escaping pipeline as N (or replicates it): first escape backslashes, then escape double quotes, then convert any embedded newlines to \n. This preserves the string contents while ensuring the resulting Python code snippet stays syntactically valid for any user input. Concretely, within generateCodeSnippet in litellm/proxy/_experimental/out/_next/static/chunks/4e4d0f466b5c1780.js, update the template expression used to build the prompt line for the TRANSCRIPTION case to:

prompt="${l.replace(/\\/g,"\\\\").replace(/"/g,'\\"').replace(/\n/g,"\\n")}"

No new imports or helper functions are needed, as this uses only core JavaScript string operations already used earlier in the same function.

In general, when interpolating arbitrary text into a string literal for another language (here: Python), all characters with special meaning in that language’s string syntax must be escaped consistently. For Python double-quoted strings, that includes at least backslashes and double quotes, and often newlines as well for readability. The current code only escapes double quotes, which leaves backslashes (and newlines) able to alter the intended literal.

The best targeted fix is to process r with the same escaping pattern used earlier in the file for S (on line 1): first escape backslashes, then escape double quotes, and optionally normalize newlines. That is, change r.replace(/"/g,'\\"') to a chained replacement that escapes backslashes and quotes (and we can mirror the earlier S behavior exactly). This preserves existing behavior for inputs without backslashes while making prompts containing paths, escape sequences, or backslash-heavy content safe and accurately represented in the generated Python code.

Concretely, in litellm/proxy/_experimental/out/_next/static/chunks/630519be35a58cb0.js, locate the section building the TRANSCRIPTION code snippet (around lines 390–394). Inside the template literal for prompt="...", replace:

prompt="${r.replace(/"/g,'\\"')}"

with:

prompt="${r.replace(/\\/g,"\\\\").replace(/"/g,'\\"').replace(/\n/g,"\\n")}"

This introduces proper escaping of backslashes and newlines in addition to the existing double-quote escaping, matching the earlier S transformation and avoiding incomplete escaping.

In general, when embedding arbitrary text into a string literal in generated code, escape all characters that have special meaning in that language’s string syntax, not just quotes. For a Python double-quoted string, this means you should escape backslashes first, then double quotes, and also convert newlines to \n so the literal stays on one line in the generated file.

In this file, the problematic code is in generateCodeSnippet's case o.TRANSCRIPTION block, around line 392–393:

392: 	file=audio_file${n?`,
393: 	prompt="${n.replace(/"/g,'\\"')}"`:""}

We should mirror the more robust escaping already used earlier for C (variable w), by first replacing \ with \\, then " with \", and then newlines with \n. That yields:

prompt="${n.replace(/\\/g,"\\\\").replace(/"/g,'\\"').replace(/\n/g,"\\n")}"

This change is confined to the shown snippet and does not alter existing functionality beyond correctly escaping additional meta-characters.