connector-jcode scrubs launch failures to 'startup failed (unknown)', hiding refusals the connector itself can name

[davidfarah2003]

Observed (2026-08-24, production box)

A jcode seat whose first readiness turn was refused by the provider gateway (400 model_not_found on a provider-prefixed model id) surfaced to the operator only as:

✗ <name> exited on launch - last output: [cotal-jcode] fatal: Jcode host startup failed (unknown); inspect the private Jcode logs.

Diagnosing required digging the seat's private logs/jcode-*.log, where the actual cause was one precise line: the gateway's 400 response naming the rejected model id. The scrubbing is right as a default posture for a private-home harness, but here it hid information the connector itself originated or can classify.

Ask

The in-flight variant→reasoning-effort work adds a narrow render path for self-generated refusals (attempted tier named in the launch error). The model-id refusal class deserves the same treatment: when the readiness turn dies on a provider 4xx, surface the provider's error code and the offending parameter value (model id / effort tier) in the launch error, keeping everything else scrubbed.

Related: 0.28.0 already moved one instance of this class to the launch boundary ("refuses a provider-prefixed model id ... refused where the accepted form can be named"); this issue asks for the same principle at the readiness-turn boundary for whatever the launch-time validation cannot catch.

[davidfarah2003]

Phase-1 triage: confirmed at ccd99461 — first-hand operator evidence, not an independent reproduction

Reproduced incidentally rather than deliberately, which is the useful part: this issue's cost was paid before it was recognised.

The claim, as a testable sentence

A jcode seat whose first readiness turn is refused by the provider surfaces to the operator only as startup failed (unknown), while the private log holds one line naming the actual cause.

What the operator saw

✗ repro-360 exited on launch - last output: [cotal-jcode] fatal: Jcode host startup failed
  (unknown); inspect the private Jcode logs.

Identical text for every failed seat, regardless of cause.

What the private log held, at the same moment

~/.cotal/jcode/<space>-<seat>-<id>/logs/jcode-2026-08-27.log:

status: 429 Too Many Requests
response: {"error":{"code":"model_cooldown","message":"All credentials for model glm-5.3
           are cooling down","model":"glm-5.3","reset_seconds":1075,"reset_time":"17m54s"}}

That single line carries the provider code (model_cooldown), the offending parameter (glm-5.3), whether it is transient, and exactly how long until it clears. None of it reaches the operator.

A second refusal class: withdrawn

An earlier version of this comment reported a 401 authorized_error on deepseek-v4-flash as a second refusal class. That was wrong and is withdrawn. Those 401s are a background scheduled catalog sweep against https://api.minimax.io/v1/models and api.openai.com — providers with no key configured on this box — and they are not on the spawn path at all:

[03:30:28.956] Failed to refresh OpenAI-compatible profile model catalog in background
               (scheduled catalog sweep): MiniMax (...)
  endpoint: https://api.minimax.io/v1/models
  status: 401 Unauthorized
  response: {"type":"error","error":{"type":"authorized_error","message":"login fail: ..."}}

A grep for 401 returns a real match, a correct count, and an entirely unrelated answer. Seats spawn successfully on deepseek-v4-flash on this box. The 429 model_cooldown case below stands; it was observed end to end.

The measured cost

Diagnosis went the wrong way for roughly an hour. The uniform message across several seats, plus seats that started and never joined the roster, reads as a mesh or lifecycle fault, so that is what was investigated: manager capacity, spawn acceptance, and the join path were all examined first. Five seats were spent before the private log was read. The first line of that log ended the investigation.

One further consequence, since a (unknown) gives no guidance on retry: repeated spawn attempts were used to test whether the condition had cleared, and each attempt refreshed the cooldown window — measured going 6m24s → 1m2s → 26m16s after one more probe. Had the launch error carried reset_time, no probing would have been necessary.

The same (unknown) also covers a completely different fault

Later the same session, seats died with the identical operator string while the provider was healthy — zero cooldowns, never past retry attempt 1/8. The actual cause was a seat-name collision: a reused agent name still has a session home, so the new process resumed a dead session, hit another client is still connected, and was killed:

[06:22:28.608] Server received SIGTERM, shutting down gracefully
[06:22:29.192] Received SIGHUP in TUI process

So startup failed (unknown) covered a provider refusal and a local kill on the same box within one hour, with no way to tell them apart from the operator surface. That cost a second wrong diagnosis: the provider remedy was applied three times, and each time the seats still died, because the cause had already changed. A launch error that distinguished "refused by provider, clears in 17m54s" from "killed, session collision" would have ended both investigations at the first line.

Verification

Six seats failed this way on one box in one session. For two of them (repro-360, repro-356) both halves are in hand — the scrubbed (unknown) launch error and that same seat's private-log line — which is what establishes the pairing. The other four are private-log evidence only: their spawns returned the 40-second accepted-but-no-terminal timeout instead of an exited on launch line, so the launch error was never rendered for them.

A control spawn issued outside the triage pipeline entirely reproduced the same private-log refusal, so this is not a property of the calling program.

Not tested: whether the connector can classify these codes at the point the error is rendered, or only observe them; the 400 model_not_found case in the original report; any provider other than the cliproxy gateway; and how a 401 renders at the launch boundary. This is first-hand operator evidence: I hit this in production and am quoting my own logs. No independent reproducer verified it, and I am the least independent witness available.