Custom Inference: setting a Model alias appends a carriage return to the model name sent to the endpoint

[mwolfe08]

Summary

On a Custom Inference endpoint, filling in the optional Model alias field causes
the request to be sent with a trailing carriage return glued to the Model name
value. The provider then rejects it with a "model not found" error, because
glm-5.2:cloud\r is not an exact match for glm-5.2:cloud.

Clearing the Model alias field makes the same endpoint, model, and API key work
immediately. Nothing else changes.

The UI describes this field as "aliases for the model picker in your input", i.e.
a display label. It should not affect the wire payload at all.

Environment

• Warp v0.2026.07.29.09.05.stable_02 (stable)
• Windows 11, 10.0.26200
• API schema: OpenAI Chat Completions
• Endpoint URL: https://ollama.com/v1
• Model name: glm-5.2:cloud
• Model alias: a short display label along the lines of GLM 5.2. I did not record
  the exact string, but it was a plain human-readable label -- not the model
  name, and not something I would have pasted from a file.

Steps to reproduce

1. Settings -> AI -> Custom Inference -> Add custom model.
2. API schema: OpenAI Chat Completions. Endpoint URL: https://ollama.com/v1.
   Provide a valid API key for the provider.
3. Add a model with Model name = glm-5.2:cloud.
4. Fill in Model alias with any short display label (e.g. GLM 5.2).
5. Save, select that model, and send any agent request.

Expected

The request body carries "model": "glm-5.2:cloud". The alias is used only as the
label in the model picker.

Actual

The request fails:

Response stream finished unexpectedly with internal error:
POST "https://ollama.com/v1/chat/completions": 404 Not Found
{"message":"model \"glm-5.2:cloud\\r\" not found","type":"not_found_error","param":null,"code":null}

Note the \r in the model name echoed back by the provider. The model tag itself is
valid (glm-5.2:cloud is a published tag; ollama.com/library/glm-5.2/tags lists
tools, thinking, cloud), and the same key and endpoint succeed once the alias
is cleared.

Workaround

Leave Model alias empty.

Hypothesis (unverified)

Looks like CRLF-vs-LF handling when the model list is serialized/deserialized on
Windows: if rows are stored as a newline-delimited blob written with CRLF and then
split on \n only, the trailing \r stays attached to the last field of each row.
That would explain why the corruption appears only once a second field per row is
populated. I have not read the relevant code to confirm this, so treat the mechanism
as a guess -- the reproduction above is the reliable part.

Why this one is unpleasant to diagnose

The corrupting character is invisible in every UI that displays the value, and it is
not whitespace, so any trim()-style guard passes it through. The resulting error is
visually indistinguishable from a genuine typo in the model name, which sends users
hunting the endpoint URL and API key instead of the field that actually broke.

Suggested fix, independent of root cause: strip surrounding whitespace and control
characters from the model identifier before serializing it into the request body.

[oz-for-oss]

@mwolfe08

Here's what I found while triaging this issue:

The report points to Custom Inference forwarding a model identifier with an invisible trailing control character when a model alias is set. Leaving Model alias empty is a reasonable workaround until the model identifier is normalized before requests are sent.

I've flagged this for the factory auto-implement queue.

Maintainer details

I concluded that custom Inference model aliases appear to allow an unsanitized carriage return to reach the custom endpoint model slug on Windows, causing provider-side model lookup failures..

Triage summary

This looks like a client-side Custom Inference bug in the Settings → AI custom endpoint flow. The report is strong: the same endpoint, key, and model work when the alias is empty, and the provider error explicitly echoes the requested model as glm-5.2:cloud\r.

Relevant code paths:

• app/src/settings_view/custom_inference_modal.rs reads the model-name and alias editor buffers in save() and emits them without normalizing the stored model identifier.
• crates/ai/src/api_keys.rs stores those values in CustomEndpointModel and later serializes CustomEndpointModel.name directly as CustomModel.slug in custom_model_providers_for_request().
• app/src/ai/agent/api.rs attaches that custom model provider registry to each agent request when custom inference is enabled.
• app/src/ai/llms.rs builds picker entries from the alias-or-name display label, so alias display and request slug are meant to remain separate.

The reporter's CRLF serialization explanation is still unverified, but the current code path does not appear to strip surrounding control characters from the model identifier before it is persisted or sent. A narrow fix would likely normalize model endpoint fields at save time and/or before request serialization, with a regression test that a model name like glm-5.2:cloud\r is never forwarded as the request slug.

Dedupe: I checked all open issues plus recently closed issues in the allowed window. Related Custom Inference/BYOK issues exist, but I did not find two existing issues with this alias-triggered trailing-carriage-return model-slug failure, so this should not be marked duplicate.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[warp-agent-staging]

Draft PR with a fix: #14787

Root cause confirmed in code — the CRLF-serialization hypothesis in the report doesn't hold (nothing stores the model rows as a newline-delimited blob; the JSON round-trip is clean). What actually happens:

1. Nothing in the custom-endpoint path normalized the entered values. The settings modal copies the editor buffer verbatim (trim() is only used for emptiness checks), ApiKeyManager persists it verbatim, and the request builder sends the model name verbatim as the wire model slug.
2. A line break can enter those single-line fields as inserted text rather than through the newline action: a clipboard payload copied on Windows carries \r\n (single-line fields convert \n to a space but the \r was left behind), and the windowing backend dispatches the typed characters of an unhandled Enter press, which Windows reports as "\r".

Since a carriage return paints as nothing, the value looks correct everywhere while the request fails.

The fix strips line breaks from user text inserted into single-line editors, collapses CRLF before the newline-to-space conversion, and strips control characters plus trims the custom-endpoint fields both when saving and when loading from secure storage — so an endpoint that is already corrupted on disk will start working again after updating, without needing to re-enter anything. Regression tests were added for each layer.

[warp-agent-staging]

Draft PR opened: #14794

Root cause turned out to be two things, and the CRLF-serialization hypothesis in the report was not one of them (secure storage writes raw bytes and does no line-ending translation):

1. ApiKeyManager::custom_model_providers_for_request() forwarded CustomEndpointModel.name to the wire as CustomModel.slug verbatim, so anything in the stored name reached the provider.
2. The \r gets into the field through key input. winit reports "\r" as KeyEvent::text for Enter, and when that key event goes unhandled the event loop falls back to dispatching it as typed characters, which a single-line editor inserted verbatim. Pressing Enter to move from Model name to Model alias is what leaves the stray \r behind — which is exactly why the corruption only shows up once the alias is filled in. macOS is unaffected because Cocoa routes those keys to doCommandBySelector:, which is a no-op for us.

The fix sanitizes the model identifier both when persisting an endpoint and when building the request, so an already-corrupted configuration heals on the next request without re-editing anything, and additionally stops single-line editors from accepting typed line breaks.

Note that the PR body is explicit about what could not be verified: there was no way to exercise the Windows GUI from this environment, so the end-to-end repro is inferred from the input code paths rather than observed.