…oo-Code-Org#1339)

* fix(zoo-gateway): stop inventing UI cost from default model prices

Stale in-memory model maps and defaultModelInfo $/token fallback made the panel overstate spend vs gateway billing after new catalog models (e.g. Alibaba promo).

* fix(zoo-gateway): negative-cache missing models and cover unset usage.cost

Avoid refetching the catalog on every request when an id is still absent after a fetch; retry after a short TTL. Add coverage for usage chunks that omit cost.

* fix(zoo-gateway): negative-cache empty catalog misses too

An empty getModels() result still records a missing-id attempt; the retry guard no longer requires a non-empty models map.

* fix(zoo-gateway): refresh catalog before negative-caching a miss

getModels can return a stale shared catalog for non-auth-scoped providers.
Force refreshModels when the selected id is still missing so newly listed
models are not blocked for the five-minute negative-cache window.

* fix(zoo-gateway): include refreshModels in RouterProvider test mocks

fetchModel now calls refreshModels on catalog misses; provider specs that
mocked only getModels broke under CI.

…g#1333)

* test(webview): add WCAG contrast audit

* test(webview): add contrast snapshot baselines

* test(webview): harden contrast assertions

* test(webview): refresh resting contrast baselines

* test(webview): refresh focus contrast baselines

* fix(webview): strengthen field focus contrast

* test(webview): capture accessible focus baselines

* test(webview): assign visual fixtures to CT coverage

* docs(webview): document CI visual baseline fallback

* test(webview): snapshot production chat and UI settings

* fix(webview): scope visual test type shim

* fix(webview): align contrast tests with modern themes

* test(webview): add pinned production baselines

* test(webview): refresh modern theme baselines

* test(webview): refresh light dialog baseline

* test(webview): isolate settings theme surfaces

* test(webview): refresh light settings baselines

* test(webview): generate themes from pinned VS Code

* test(webview): refresh generated theme baselines

* test(webview): align generated theme expectations

* test(webview): refresh interactive theme states

* test(webview): refresh focused theme baselines

* test(webview): refresh dark dialog baseline

* ci(webview): check generated theme drift

* test(webview): stabilize generated theme fonts

* test(webview): normalize fixture typography

* test(webview): cover theme fixture validation

* refactor(theme-fixtures): move theme probe off the public API

* fix(webview): restore button mock styles lost in theme migration

* test(webview): cover theme probe lifecycle

---------

Co-authored-by: Roomote <[email protected]>
Co-authored-by: Elliott de Launay <[email protected]>

Co-authored-by: @navedmerchant <[email protected]>

* feat: Add Read+Write allowlists. Fixes Zoo-Code-Org#1273

Enables giving Read or Write access to specific files, without giving
full access on the workspace.

This is the equivalent of the existing auto-approve-commands
allowlist, but for files (and much safer, and easier to implement).

Useful to restrict the agent e.g. to write notes that survive
task switches and context condensation.

Example use cases:

* You could use this to tell the agent to keep a coarse
  log of what's being done in `./notes.md`, and you won't have
  to manually approve updates to that even if otherwise you
  review-and-approve every diff.
  This is expecially useful because many LLMs' context condensation
  is not very good: They will "forget" key commands upon condensation,
  thus starting to make mistakes or ask the user to help.
  With a reliable notes document where they can look up commands,
  this problem diappears.

* Let Zoo sift through large amounts of data
  (larger than the context window) unattended in a mostly-read-only
  fashion but with the need to remember results reliably
  (unaffected by context compression).
  For example, if you have 1000 large text documents and want the LLM
  to record all occurrences of specific topics,
  without giving Write permissions to all files.

* In the Zoo repo to allow automatic Auto-Approve
  only for `./webview-ui/src/i18n/**` to update translations.

* Auto-approving writes to a specific file outside the workspace,
  such as `~/.gitconfig` when asking the agent to help you
  iterate on Git configuration.

LLM: Done with Claude Opus 5 in Zoo Code, human review.

* FIXUP: Claude review

* FIXUP: Address PR review comments

* FIXUP: Address latest review nits

* FIXUP: More review feedback, allow testing Windows behaviour on non-Windows

* FIXUP: Fix test

…-Code-Org#1243)

* fix(openai-codex): complete prompts over the streaming transport

The Codex subscription endpoint only accepts streaming requests, so
`completePrompt` sending `stream: false` was rejected outright with
HTTP 400 `Stream must be set to true`. That made commit-message
generation, prompt enhancement and condensing unusable on Codex.

Rather than issue its own request, `completePrompt` now runs the
existing streaming path and joins the text chunks. That inherits the
OAuth refresh-and-retry, the SDK-then-SSE fallback and the Luna body
instead of duplicating a second, subtly different request builder.
Reasoning chunks are deliberately dropped: a commit message is written
straight into the Source Control box.

A caller's abort signal also never reached the wire, since both
transports abort through the handler's own controller. It is now linked
to that controller, so stopping a generation actually cancels it.

The spec asserted `stream: false`, pinning the bug in place; it now
asserts the opposite and covers chunk joining, reasoning exclusion,
auth retry and signal propagation.

Co-Authored-By: Claude Opus 5 <[email protected]>

* fix(openai-codex): stop replaying the stream and treat an abort as one

Two problems in the streaming completePrompt path.

The SDK stream and its consumption loop sat inside the same try, so an
error raised part way through the stream was handled as "the SDK could
not be used at all" and the request was replayed over SSE. Whatever the
SDK had already yielded stayed with the caller, so the replay appended a
second generation to the first. The fallback now closes after the first
SDK event, which is the point where the request has been accepted and
its output is already out. It is set before processEvent runs, since
that mutates response state too, so a throw from it must not replay
either. This covers the chat path as well, since both go through
executeRequest.

Both transports also end quietly on abort, breaking out of their loops
rather than throwing, so completePrompt returned whatever partial text
had arrived and callers read a cancelled generation as a finished one.
It now rejects with an AbortError instead, and a cancellation is passed
through rather than reported to telemetry or relabelled as a completion
error, since stopping is the caller's own doing.

The two abort specs asserted that a cancelled call resolves, which held
the bug in place. They now assert the rejection and cover the pre
aborted and mid stream cases, and a new spec covers the mid stream SDK
failure and checks that SSE is never reached.

Co-Authored-By: Claude Opus 5 <[email protected]>

* fix(openai-codex): close the last two replay routes into a live request

Follow-ups to the previous commit, both raised by CodeRabbit.

Closing the SSE fallback after the first SDK event left the OAuth retry
loop as a second way back into a request the service had already
accepted. A mid stream error that reads as an auth failure would refresh
the token and send the whole thing again, so completePrompt could
concatenate two generations and the chat path could repeat streamed
effects. The flag moved onto the handler, reset per request alongside
the other response state, and the retry is now skipped once the SDK has
emitted. A refresh before any event still retries as before, which is
the case that loop exists for.

An abort also still reached the fallback, since the SDK rejects when the
caller cancels and that read as a transport failure. It spent a second
request on an already aborted signal and reported the cancellation as a
connection error. The fallback now rethrows instead.

Specs for both, plus a check that the pre event refresh path is
untouched.

* fix(openai-codex): report one abort result however the request ended

Chasing a review comment about the cancellation tests turned up a real
inconsistency behind it. A stream that ended quietly threw an AbortError,
but a transport that rejected on abort had its own error passed straight
through, so what a cancelled completePrompt rejected with depended on how
far the request had got. Callers cannot key off that. An abort is now
restated as an AbortError unless it already is one.

The in flight case, where the caller cancels after the request is away
but before any event, had no coverage. It only works if the caller signal
is genuinely linked to the internal controller, so it is the case that
would catch that link breaking. Added, and it waits for the request to be
in flight before aborting, since the token lookup and the listener are
both async and a synchronous abort fires before anything is listening.

Also tightened the existing abort assertion from a bare rejects.toThrow,
which passed on any error at all, to the same AbortError check the other
cancellation tests use.

* fix(openai-codex): keep refusals out of the completed prompt

completePrompt joined every text chunk, and a refusal is streamed as text so
the chat can show it. The non-streaming request this replaced read output_text,
which never carries refusals, so it returned "". The streaming version instead
handed the prompt enhancer "[Refusal] ..." to paste into the input box as if the
model had answered.

The prefix both refusal branches emit is now a shared constant, and
completePrompt skips the chunks carrying it - any real output_text alongside a
refusal still comes back, matching what output_text held.

Also corrects the comment naming commit-message generation as the caller. The
prompt enhancer is the only one.

Co-Authored-By: Claude Opus 5 <[email protected]>
@

---------

Co-authored-by: Claude Opus 5 <[email protected]>

* fix(nanogpt): serialize Muse Spark tool calls

* fix(nanogpt): preserve Muse tool-result context

---------

Co-authored-by: @navedmerchant <[email protected]>

…Zoo-Code-Org#1323)

When a task is interrupted while an assistant turn's tool calls (e.g. attempt_completion) are unanswered, resumeTaskFromHistory synthesizes tool_result blocks to keep the API conversation valid. Those synthetic blocks lacked is_error: true, so the persisted api_conversation_history.json ends with a success-looking completion while the task list records the task as interrupted - any consumer inferring completion from history is fooled.

Set is_error: true on both synthetic tool_result sites (assistant-last and missing-results cases), matching the existing error tool_result pattern used for new_task truncation. Adds two regression tests covering both code paths.

Co-authored-by: Eason Liang <[email protected]>

Co-authored-by: Roomote <[email protected]>

Co-authored-by: Roomote <[email protected]>

…Zoo-Code-Org#1352)

* fix(services): handle background promise failures

* test(code-index): cover threshold batch cleanup

---------

Co-authored-by: Roomote <[email protected]>

…ator