* ⏭️ feat: Honor an Interrupt Before the Model Has Answered
An interrupt armed while the model is still thinking sat as "Interrupting"
until the entire turn finished, then landed as a terminal continuation. The
cause is upstream: the SDK reads `shouldPreempt` once per streamed chunk, and
its seal gate requires non-empty text — so a silent provider is never polled at
all, and a reasoning-only turn is never sealable.
`@librechat/agents` gains a discard-and-restart path for exactly that window
(`HOOK_PREEMPT_RESTART_CAPABLE`). This wires the host half:
- `GenerationJobManager.subscribePreempt` registers run-scoped wake listeners,
notified after an ACCEPTED arm — local or cross-replica, since both land in
`armPreemptIds`. Fenced on `createdAt` like every other preempt entry point,
and a throwing listener never fails the arm a queued steer depends on.
- `createSteerPreemptPoll` hands that channel to the SDK as
`StreamPreemption.subscribe`, gated on a new `isSteerPreemptRestartSupported`
probe so an SDK that cannot act on a wake is never handed one.
The wake is a hint only: `isPreemptRequested` stays the single authority, so
the level-triggered contract the seal path depends on is unchanged.
Inert until `@librechat/agents` publishes the restart contract — the probe
returns false against the pinned 3.7.11 and the run keeps today's behavior.
* 🩹 fix: Replay an Already-Armed Preempt on Subscribe
Preempt requests are level-triggered, and the window between a job becoming
steerable and the SDK installing its model-attempt listener is real. An
interrupt landing there was recorded with no callbacks to notify, and on a
silent or reasoning-only turn no later chunk poll may ever run — leaving the
request to wait out the whole turn, the exact stall this channel removes.
`subscribePreempt` now replays an existing arm to the newly registered listener
only, after registration: waking the whole set would re-notify runs that
already looked, and waking before registration would leave a concurrent arm
with nowhere to land. The `createdAt` fence is unchanged and still gates the
replay.
The SDK also reads the level flag once at each attempt's start, so this is
belt-and-braces rather than the sole cover — but it makes the host correct on
its own terms instead of resting on when the SDK happens to look.
* 🔧 chore: Update @librechat/agents dependency to version 3.7.14 in package-lock.json and related package.json files
* 🔧 chore: Update dependencies in package-lock.json and package.json
- Bump versions for @humanfs/core (0.19.1 to 0.19.2), @humanfs/node (0.16.6 to 0.16.8), @xmldom/xmldom (0.8.13 to 0.8.15), and qs (6.15.2 to 6.16.0).
- Add @humanfs/types (0.15.0) as a new dependency for @humanfs/node.
- Update dependencies for side-channel and side-channel-list to their latest versions.
* 🛑 fix: Forward Run Abort Signal to Foreground Tool Calls
Stopping a generation left in-flight tool calls running on the far side.
For MCP over streamable-http the external server kept burning CPU until
the tool finished or timed out, with no `notifications/cancelled` ever
sent.
The MCP layer was never the problem: `MCPManager.callTool` already
spreads `options.signal` into `client.request`, and the SDK's
`Protocol.request` sends `notifications/cancelled` the moment that signal
aborts. The signal simply never arrived.
Agent tools do not execute inside LangGraph's ToolNode — `eventDrivenMode`
dispatches `on_tool_execute` and `createToolExecuteHandler` invokes them.
The agents SDK puts the run's abort signal on the batch request
(`ToolExecuteBatchRequest.signal`, documented as one handlers should
forward), but the handler destructured every field except `signal` and
built its invoke config without it. `config.signal` was therefore
`undefined` in every foreground tool, so `createMCPTool` derived no
signal and the SDK registered no abort listener.
Forward it. This restores cancellation for all signal-aware foreground
tools, not just MCP. The detached background invoke keeps its own
controller, since that work deliberately outlives the turn.
An aborted call now rejects promptly and resolves an error result rather
than hanging, so the abort is logged at debug instead of as a tool error
— a user pressing Stop should not spray the error log.
* 🔇 fix: Keep Cancelled Tool Calls on the Filtered Path and Out of Error Logs
Addresses both findings from the Codex review of 48fded564a.
P1 — the cancellation branch returned before `filteredToolOutputResult`,
so with tool-output filtering configured an aborted call's error text
reached the turn uninspected. Worse, `runSignal.aborted` says the run is
over, not that this rejection was the cancellation: an unrelated failure
racing the Stop took the same unfiltered exit. Cancellation now only
selects the log level; filtering and the result shape are unchanged.
P2 — `createMCPTool` logs its own error before wrapping and rethrowing,
so every Stop during an MCP call still emitted an error-level MCP entry
and could pollute operational alerts. That catch now recognizes the abort
and logs at debug; the wrapped message still reaches the turn.
Both are covered by tests that fail against the previous commit.
* 🎯 fix: Require an Abort-Shaped Error and Spare Shared OAuth Flows
Addresses both findings from the Codex review of b3c67082cd.
An aborted run signal proves the turn is over, not that the rejection in
hand was the cancellation — a permission, OAuth, or upstream failure can
reject in the same tick a user presses Stop. Both quiet-log branches now
require the error to look like an abort as well, so a real failure racing
the Stop stays at error level and visible to operational alerts.
`isAbortError` moves to `@librechat/api` and the copy in
`abortMiddleware` is retired, keeping one implementation. Its spec pulls
the real function through its partial package mock rather than asserting
a stub.
Forwarding the run signal also reached ActionService, where two of the
three OAuth flows are keyed `userId:action_id` and so outlive the run
that opened them: a second run for the same action joins the very same
record, and the browser's OAuth callback reads its metadata to exchange
the code. `monitorFlow` deletes the key when a waiter's signal aborts, so
one Stop could strand a concurrent run and discard an authorization the
user had already granted. Those two flows no longer take the signal; the
run-scoped login flow, keyed by thread and run, still does.
Every guard is covered by a test that fails when the guard is removed.
* 🧷 fix: Detach the Stopped OAuth Waiter Instead of Dropping Its Signal
Addresses the Codex review of d53ff170ab.
Withholding the run signal from the shared Action OAuth flows protected
concurrent runs and the browser callback, but left this invocation
attached to the flow after the Stop. A callback landing late then resumed
`_call` straight into `preparedExecutor.execute` — a consequential API
request running after the user had already stopped the turn. Handing the
signal back is not the answer either, since `monitorFlow` deletes the
shared `userId:action_id` key on abort.
`detachOnAbort` separates the two: the caller stops waiting the moment
the signal aborts, while the shared flow runs on for whoever else needs
it — another run, or the callback exchanging its code. Late settlement of
the detached work is swallowed rather than surfacing as an unhandled
rejection.
Both shared flows now use it. The run-scoped login flow keeps the signal
directly, as nothing outside its run observes it.
* 🪪 fix: Keep an Action OAuth Abort an Abort
Addresses two of the three findings from the Codex review of 70fc0782b1.
Detaching the stopped waiter left the rejection to be misread on the way
out. The refresh catch treated it as a failed refresh and called
`requestLogin()`, emitting an OAuth prompt and opening pending
authorization state for a turn that had already ended. `requestLogin` and
the surrounding auth catch relabelled it `Failed to authenticate OAuth
tool` / `Authentication failed`, and the outer catch handed that to
`logAxiosError` — so an ordinary Stop produced two error-level entries
and returned failure text as the tool's result. Each boundary now lets an
abort through unchanged, and the outer catch logs it at debug and
rethrows so it stays a cancellation end to end.
Deferred: waiter-only cancellation in `FlowStateManager`, so a detached
`monitorFlow` stops polling instead of running out the flow's TTL. That
poller is bounded at three minutes and lives exactly as long as it does
for a waiter that never left, so it changes no lifetime this branch
introduced; giving `FlowStateManager` a non-destructive abort mode is its
own change, shared with MCP and indexSync.
* 🤫 fix: Classify the Abort at the MCPManager Boundary Too
Addresses the Codex review of 9bcf1aa57e.
`MCPManager.callTool` logs every rejection at error level before
rethrowing to `createMCPTool`, so a user Stop still emitted an MCP error
from the inner boundary even after the outer one learned to recognize it.
The same signal-plus-abort-shape classification now applies here.
The review also noted, correctly, that the existing test could not have
caught this: it replaces `getMCPManager` wholesale, so it only ever
exercised the outer logger. The new cases drive the real manager with a
connection whose `client.request` rejects the way the SDK does once a
request signal aborts, and cover both the cancellation and a genuine
failure racing the Stop.
* 🧹 chore: Restore Import Order in the Agents Tool Handler
Claude Fable 5.1 (`claude-fable-5-1`, GA 2026-09-01) succeeds Claude Fable 5
at the same input/output prices, with a 1M context window and 128K max output.
The Mythos-class helpers added for Fable 5 already match it — `isMythosClassModel`
tests `claude-(?:fable|mythos)[-.]?\d`, so adaptive thinking, summarized-display
opt-in, sampling omission, 1M context, the 128K output clamp, prompt caching,
the Vertex multi-region gate, and the Bedrock PDF exemption all cover 5.1
without a code change. What was missing was registration and pricing.
Cache reads are the one rate that differs, and the substring matcher would have
silently gotten it wrong: `claude-fable-5-1` falls through to the `claude-fable-5`
key, which prices cache hits at the usual 0.1x base input ($1/MTok). Fable 5.1
and Mythos 5.1 price them at 0.025x ($0.25/MTok), so every cache read would have
billed 4x — on exactly the long agentic sessions this model is built for.
- Register `claude-fable-5-1` in the shared Anthropic list and
`global.anthropic.claude-fable-5-1` in the Bedrock list
- Add 1M context / 128K output entries for `claude-fable-5-1` and
`claude-mythos-5-1`
- Add $10/$50 rates and `{ write: 12.5, read: 0.25 }` cache rates for both
- Update the `.env.example` and Vertex `librechat.example.yaml` examples
- Test that 5.1 resolves to its own key rather than collapsing onto 5.0, across
token maps, pricing, cache rates, and Mythos-class detection
The three documented breaking changes from Fable 5 need no handling here:
LibreChat never sends a forced `tool_choice` on the Anthropic path (the agents
SDK omits the param when unset, so the API default `auto` applies); thinking
blocks an earlier model can't read are dropped server-side, unbilled; and
history is rebuilt from stored content parts rather than replayed signed
thinking blocks, so the prefix-binding check has nothing to reject.
Refs #15506
Queue a message during a run — queue, not steer — and the row is server-owned:
`useQueueDrain` deliberately declines the boundary (`serverOwnsBoundary`) and
the backend admits the successor itself. So the client has to hear about that
run through the active-job list, exactly like a background-tool continuation.
It cannot. Finishing a run empties the list — the client removes its own job
optimistically the moment FINAL lands — and the poll is disabled on an empty
list, so it goes quiet at precisely the moment the successor is admitted. With
the tab already focused there is no focus refetch either, which is why this
reproduces on desktop and not only on mobile. The announcement never arrives,
so the re-arm never runs and the pane sits on the previous turn until a reload.
Keep asking for a bounded window after the last known job ends. The window is
module-scoped rather than per-observer because this is one shared query and a
component mounting mid-handover should inherit the grace, not restart it.
This is the other half of the previous commits: without the re-arm the
announcement lands on a pane that still reads its finished submission as an
attachment, and without this the announcement never lands at all. Neither half
is observable alone.
* 🔁 fix: Recover Keyv Redis Client From READONLY Replica After Failover
When a Sentinel failover demotes the master a pod is connected to, the
ioredis client recovers through `reconnectOnError`, but the Keyv/node-redis
client never does: `socket.reconnectStrategy` only runs when the socket
closes, and a demoted replica keeps existing sockets open while rejecting
every write with `READONLY`. Every cache write through the Keyv client
(USER_PRINCIPALS, MCP catalog, server configs) then fails until restart.
- Add a READONLY recovery hook for the standalone node-redis client that
tears the socket down and reconnects, re-resolving to the current master
- Debounce attempts with `REDIS_READONLY_RECOVERY_INTERVAL` (5s default)
and retry on the next error, since a reconnect issued before the
topology settles can land on the demoted node again
- Route all three surfaces where READONLY replies appear through the hook:
the client error event, the Keyv cache error funnel, and Lua scripts
evaluated via `evalKeyvRedisScript`, which reject straight to callers
- Skip cluster clients, which follow MOVED to the owning master already
- Cover the hook with a fake RESP server so real node-redis and Keyv code
paths are exercised against a node whose role flips mid-connection
Fixes#15500
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WNbgMeR2aZDyhsqAy4L8gF
* 🛟 fix: Harden READONLY Recovery Retry, Clear Path, and Clock
Address review findings on the READONLY failover recovery:
- Retry on the next error of any kind after a failed reconnect. A failed
`connect()` leaves the client closed, so later failures surface as
ClientClosedError rather than READONLY and the hook never fired again
- Route the namespace `clear()` override through recovery. It deletes
through the raw client, bypassing the Keyv error funnel, so a READONLY
rejection there previously left the pod stranded
- Debounce on an injectable monotonic clock (`performance.now`) instead of
`Date.now`, so wall-clock steps cannot suppress or duplicate attempts;
the interval test drives the clock instead of sleeping
- Reuse `isReadonlyReplicaError` in the ioredis `reconnectOnError` hook so
READONLY detection has one definition
- Document the in-flight command rejection that a socket teardown implies
Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WNbgMeR2aZDyhsqAy4L8gF
* 🛟 fix: Gate READONLY Recovery on Client State
Address the second review pass on the READONLY failover recovery:
- Act only on a client the hook can reason about: a READONLY reply on a
ready socket, or a client its own failed reconnect left closed. While
node-redis runs its own reconnect loop (open but not ready) the hook
stays out, since a second `connect()` would start a concurrent loop
that leaks sockets into one shared reply decoder
- Clear the pending retry whenever an error arrives on a ready client, so
a client that Keyv auto-connected after a failed attempt is never torn
down by a later unrelated error
- Drop the client error-event wiring: node-redis rejects command error
replies straight to the command promise and emits `error` only from its
socket and connect loop, so that listener could never see a READONLY
reply and only fed connect-loop errors back into the hook
- Cover the connect-loop, self-recovered, and Keyv auto-connect outage
cases, and a rejected namespace clear, with a SCAN-aware RESP server
- Add the new export to the `redisClients` mocks in the cacheFactory specs
* 🔧 fix: Update sanitize-html to version 2.17.7 in package.json and package-lock.json
* 🔧 chore: Update postcss-selector-parser to versions 6.1.3 and 7.1.3 in package.json
* feat: Handle reaching the agent tool-call limit gracefully
When the graph exhausts its per-turn step budget, persist the turn as
unfinished with finish_reason tool_call_limit instead of a red error.
Warn the model as the budget runs low, and offer Keep going or Answer now.
* docs: Add screenshots of the tool-call-limit notice
Light and dark captures of the unfinished-turn card for the PR description.
* style: Tighten the tool-call-limit notice card
Pin dismiss to the top-right with uniform rounding, use a slightly
smaller hit target, and round the card to xl. Refresh the PR screenshots.
* fix: Address Copilot review findings on the step-budget path
Skip empty and subagent-scoped PostToolBatch events when counting
rounds. Drop the double-cast in the notice test helper and coerce the
tool-call-limit finish reason in the Continue-gate spec.
* fix: Address Codex review findings on budget and dismiss
Pass the resolved recursion limit into the OpenAI-compatible
processStream path so the step-budget hook matches the graph.
Reset the notice dismiss state when the displayed message id changes.
* fix: Unblock CI typecheck and import sorting
Declare recursion_limit on the OpenAI service agent type, sort that
file's local imports, and route the notice test context through unknown
so tsc accepts the partial ChatContext fixture.
* fix: Sort remaining PR imports for static checks
* chore: Remove tool-call-limit notice screenshots
* fix: Keep recovery actions from consuming composer drafts
Pass empty file, skill, and quote overrides on Keep going and Answer
now so a staged compose is not attached or drained.
* 🔄 fix: Reindex MeiliSearch Documents After Indexed-Projection Changes
- Introduce _meiliIndexSchemaVersion schema field and MEILI_INDEX_SCHEMA_VERSION constant
- Stamp schema version on single-document and batch index writes
- Query unindexed and stale-version documents in syncWithMeili
- Count stale documents in pendingIndexing in getSyncProgress
- Add spec coverage for reindexing stale-version documents
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* 🔄 test: use the registered Meili conversation model
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* 🔄 style: satisfy Prettier in Meili indexing progress counts
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Co-authored-by: Danny Avila <danny@librechat.ai>
* 🔍 fix: Include Message-Matched Conversations in Sidebar Search
- Union conversation and message index matches in getConvosByCursor
- Type searchMessages with SearchParams and SchemaWithMeiliMethods
- Inject searchMessages into createConversationMethods
- Bound sidebar Meili queries with 1000 limit and attributesToRetrieve
- Fall back to title-only matches when message search fails or is uninjected
- Escape filter user values in search queries
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* fix(search): preserve original conversation keys in sidebar hits
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* 🔍 fix: reuse the loaded conversation model
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* 🔍 fix: type the loaded conversation search model
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
`createPayload` interpolated the endpoint name straight into the chat URL,
so a custom endpoint named `Company/API` produced
`/api/agents/chat/Company/API`. The slash reads as a path separator, the
request no longer matches the router's `/:endpoint`, and it falls through
to the catch-all handler, which answers `404 Endpoint not found`.
Encoding the name keeps it a single path segment. Express matches the
encoded segment and decodes it back, and the endpoint the server acts on
comes from the request body regardless, so nothing else has to change.
Closes#15270
* fix(api): align message search with page size
Pass a positive, capped page size to MeiliSearch and use the same conversation limit so requested message search pages are not silently truncated.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* fix(data-schemas): expand shared-link search results
Request the MeiliSearch result ceiling using only conversationId so cursor pagination is not limited to the default 20 hits or burdened with unused fields.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* 🚧 fix: Narrow Chat MCP Selections to What the Picker May Offer
The chat MCP picker offers a server only when the operator has not hidden it
(`chatMenu: false`) and the user reaches it directly rather than through an
agent (`consumeOnly`). Nothing enforced either condition on the request, so a
stale client, a replayed body, or a hand-written one could name any server and
get its tools — `consumeOnly` in particular is a permission the registry derives
per user, so ignoring it let a user reach in plain chat a server they had only
been granted through an agent.
Narrow the picker's selection in the two ephemeral loaders, against the same
predicate the client's `selectableServers` uses. The resolver is injected, so
`packages/api` stays free of the registry and the loaders keep their existing
`deps` shape.
Provenance is why this lives in the loaders rather than at the tool-resolution
chokepoint: only here is a server name known to have come from the picker.
Servers a model spec pins are the operator's own choice and are added after the
narrowing, so pinning a chat-hidden server to a spec keeps working.
`chatMenu` only ever comes from the config tier, so the overlay settles it with
no lookup at all. Lookups for the rest run concurrently and are cached per
server and user. A name the registry cannot resolve — request-tier, declared on
the body and never registered — is kept, as is one whose lookup fails: this
narrows an already-authenticated selection and is not the authorization
boundary.
* 📝 docs: Say What chatMenu Now Bounds
The schema still described `chatMenu` as dropdown visibility alone, which is
misleading now that it also bars a server from the chat selection a request
carries. Spell out both halves, and what it deliberately does not restrict:
agents, and servers a model spec pins.
* 🛡️ fix: Close Four Gaps in the Chat MCP Narrowing
Dedupe before resolving. The selection is request-supplied and the loaders used
to build a `Set` immediately; mapping the raw array first let one body repeat a
name enough times to launch a resolver — registry, cache, and ACL reads, with no
single-flight — per occurrence.
Resolve names through the tool-loading aliases. A configured `private server` is
addressable as `private_server` downstream, so an exact-key lookup let the
normalized spelling walk past a `chatMenu: false` check and still load tools.
Names are returned as sent; only the decision is canonicalized.
Let the request overlay settle `chatMenu`. The config tier is where the flag
lives and is what the picker itself was built from, so an overlay that re-enables
a server now outranks the durable config the registry returns, which was silently
dropping a valid selection. `consumeOnly` still comes from the registry.
Narrow the request body, not just the loader's copy. `applyContextToAgent` reads
`req.body.ephemeralAgent.mcp` directly and prefers it over the agent's tools, so
a hidden server's `serverInstructions` reached the model context even after its
tools were dropped.
* 🧭 fix: Ask the Registry Which MCP Servers the Picker May Offer
Three rounds of review found the same mistake in three disguises: this narrowing
re-derived the registry's tier precedence instead of asking for it. A config
entry was treated as authoritative over a user-DB or process-backed server of the
same name; the alias map was built from config names only, so a DB server named
`private_server` was misrouted to a config `private server`; and the overlay
short-circuit ran before any of that could be consulted.
Resolve the accessible set through `resolveAllMcpConfigs` instead — the same call
behind `GET /api/mcp/servers`, so what the request may use and what the picker
was offered come from one place and cannot drift. Precedence, cross-tier name
collisions, and the config overlay are the registry's job again, and the
selectability test is a single flag check over what it returns.
The result is smaller: no overlay branch, no per-server lookups, one catalog read
regardless of how long the selection is, and aliases built over the whole
accessible set so an exact name always outranks another server's normalized form.
Publish the servers actually in play back onto the request body, spec pins
included. `applyContextToAgent` prefers that list over the agent's tools, so
narrowing to the picker selection alone had started dropping a spec-pinned
server's `serverInstructions` while suppressing a hidden one's.
* 🔑 fix: Decode Action OAuth Credentials After Decryption
Action client credentials are URL-encoded before encryption, but the OAuth
token exchange decrypted them with `decryptV2` alone, sending values like
`abc%40domain.com` to the provider and causing 401s for secrets containing
`@`, `+`, `=`, `/` or `:`. Decoding falls back to the raw decrypted value so
legacy secrets stored before 299cabd6e (which contain an unescaped `%`) still work.
Fixes#14636
* 🔑 fix: Share Action Credential Codec Between Read Paths
The encode-before-encrypt convention had two readers with different
behaviour. `ActionService.decryptSensitiveValue` decoded unconditionally,
so a credential stored before encoding was introduced (299cabd6e, March
2025) containing a stray `%` threw `URIError` and failed every read of the
action, not just the token exchange.
Extract the pair into `packages/api/src/actions/crypto.ts` as the single
implementation and consume it from both `ActionService` and the OAuth token
exchange, so the two paths cannot drift again.
Tests cover the codec against real crypto: reserved characters and literal
percent escapes round-trip, pre-encoding values are returned unchanged, and
a pre-encoding value with a stray `%` no longer throws.
A version marker on newly encrypted values was prototyped and dropped: it
changes the stored format for every action credential while fixing nothing,
since values written by the encoding convention already decode correctly
and pre-encoding values stay unmarked either way.
---------
Co-authored-by: Danny Avila <danny@librechat.ai>
* 🫥 fix: Clear Hidden MCP Chat Selections
A server hidden with `chatMenu: false` stayed active in chat when it had been
selected while still visible. The selection persists to localStorage, and the
guard that clears stale selections tested the *filtered* server list — which is
empty precisely when every configured server is hidden, so the guard could never
fire and the selection survived every reload.
Gate the prune on the unfiltered catalog instead. It is non-empty in exactly the
case the old guard missed, and it stays a guard rather than a load flag so an
empty catalog — still loading, or a degraded read — is never mistaken for "the
admin removed everything" and used to wipe a selection irrecoverably.
Clear the ephemeral agent alongside the atom: it is what carries the selection to
the server, so a hidden name has to leave it too, not just the dropdown's state.
Also label the dropdown badge from the servers the menu actually offers. It
counted the raw selection, so a hidden server rendered as "Server Four" or
"2 selected" above an empty menu — the symptom that reads as a server you cannot
turn off.
* 🔧 fix: Keep Spec-Assigned MCP Servers Out of the Hidden-Server Prune
A model spec may deliberately assign a server the chat menu hides, and
`applyModelSpecEphemeralAgent` seeds it straight into `ephemeralAgent.mcp`. The
prune could not tell that apart from a stale selection, so activating such a spec
dropped its server — and because the same function re-reads `LAST_MCP_` for
existing conversations, the loss persisted across navigation.
Exempt whatever the active spec pins. `chatMenu` hides a picker entry; it does
not override an admin's spec assignment.
* 🔒 fix: Confine the MCP Selection Prune to the Hook Instance That Owns It
`useMCPServerManager` has seven call sites, and only `BadgeRowContext` reads the
chat selection — the rest mount it for the catalog, the server actions, or the
status icons. Every instance keyed to the same conversation shares one atom and
one ephemeral agent, so those six were all running the prune too, and the
always-mounted `useSideNavLinks` has no spec context to exempt from: it would
rewrite the selection the picker's own instance was deliberately keeping.
Make managing the selection opt-in, off by default at both layers, and let the
badge row alone opt in. The six catalog consumers stop touching chat selection
state entirely, which is what they should have been doing all along.
Tests now state whether they own the selection rather than inheriting it from a
default, so each one exercises the same configuration as the instance it models.
* 🔁 fix: Mirror the MCP Selection Everywhere, Prune It Only in the Owner
Gating the whole ephemeral-agent sync on selection ownership was too broad. The
action paths — `initializeServer`'s OAuth success, the revoke handler — build
their next selection from `mcpValues` and write it back through `setMCPValues`,
which also rewrites the shared ephemeral agent. An unmirrored instance therefore
wrote a stale list: authenticating server B could drop an existing selection of
server A, leaving only B.
Mirroring and pruning are separate concerns. Every instance mirrors, so each one
builds on the current selection; only the owner prunes, because only it knows
which servers a spec pins.
The picker never set `selection.enablePersistence`, so it dropped the current
selection every time the user opened another folder or switched pivot. A selection
could only ever be assembled from a single location — pick three files, open another
folder, and the three are gone.
One option on the picker configuration; no change to what LibreChat does with the
result.
Fixes the selection half of #15237. Folder selection — the other half — is a new
capability rather than a fix, and is parked on `feat/sharepoint-folder-selection`.
Typing a message, pasting an image, then pressing Enter did nothing: the
composer held the full draft, the send button was enabled, and Enter was
inert until the user clicked back into the textarea — which reads as
"the textarea needs a text change before it will submit".
The send gating was never at fault. Radix's modal `DialogContent` always
cancels its default close-focus restore and focuses
`context.triggerRef.current` instead. `DragDropModal` — the "Select Upload
Type" dialog a paste or a drop opens — is opened programmatically and so has
no `Dialog.Trigger`, leaving that ref null: nothing is focused and focus
falls to `document.body` when the dialog unmounts. Enter-to-send is a
keydown handler on the textarea, so from `body` it is never reached.
`UploadModalProvider` now records the element the upload was started from,
captured in `openModal` before the dialog mounts (an effect runs too late —
Radix has already moved focus), and restores it once the dialog closes,
queued behind Radix's own deferred restore. This covers every close path:
picking a destination, Cancel, Escape, and dismissing the overlay.
`OGDialog`'s existing `triggerRef` seam does not reach this case, since it
only fires through Radix's `onOpenChange` and choosing an upload destination
calls `closeModal()` directly.
* 📐 docs: Record Who Owns Which Piece of Client State
* 🔌 refactor: Give the Subagent Surface a Host Seam and Its Own Jotai State
The subagent chat surface reached up into seven application atoms and could
not be lifted anywhere, and the six atoms it owns were still Recoil while its
sibling stores had already moved to Jotai.
Feature-owned state converts to Jotai and stays where it is: the selection,
per-task control receipts, live progress and the parent-stream fence. The
control atom keeps its session-storage retry — restored per store rather than
per family member, so a reload still sees what the last one persisted.
App-global state now arrives through one `ChatSurface` value the host supplies:
`enterToSend`, `maximizeChatSpace`, `showScrollButton`, the reader's composer
bindings, a `claimForeground` command for the slot the panel and the artifacts
panel share, and `handOffComposerText` for a continuation's unsent words. Two
hosts mount the same adapter — the conversation view and the shared-link view.
Opening the panel was three copies of "clear the artifacts slot, then select";
that is now `useOpenSubagentPanel`, and the three call sites say what they mean.
Nothing under `Chat/Subagents/**` imports `~/store` or `recoil` any more, and
its whole suite runs with no `RecoilRoot` at all.
* 🧹 refactor: Move Subagent State Into the Feature and Free Its Drained Atoms
Two review findings, both fair.
The selection atom still lived in `~/store`, which handed the supposedly
liftable surface an implicit dependency on the application store alongside its
declared host interface — and contradicted the ownership rule this branch
added to CLAUDE.md two commits ago. The module moves to
`components/Chat/Subagents/state.ts`; the hosts that write it (the SSE step
handler, the message renderers) now import from the feature, which is the
direction that survives an extraction.
The conversation-switch drain blanked its two atom-family members but left
them cached. Every invocation key is unique, so a long-lived tab accumulated
two atom configurations per subagent call it ever saw — exactly what the
comment at that boundary says it exists to prevent. `removeSubagentProgressAtoms`
releases them after the values are cleared, mirroring `removeUsageAtoms`. The
new test fails without the release.
* 🔎 fix: Let a Subagent Card Render Where There Is No Panel to Open
Search results render the same card through `Part`, and that route is not
beneath either chat surface — so a search hit containing a subagent tool call
threw on `useChatSurface()` before it could render at all.
Rendering the card and opening a panel are different requirements. The host
stays required for the panel, the activity view and the event group, all of
which only ever mount inside one. `useOpenSubagentPanel` reads the context
optionally instead and answers `null` where there is no host, which is also
the honest answer for search: there is no panel on that route to open, so the
card renders with its details control disabled.
The new test renders the card with no surface at all, and throws with the
reported error when the hook is put back the way it was.
* 🧮 fix: Enrol Read-Created Progress Atoms in the Drain Registry
The read is what creates a family member, and only the streaming paths were
registering their keys. A card rendering a conversation that finished
streaming long ago — or a search result that never streams at all — created
one the navigation drain could not see, so browsing history accumulated an
atom configuration per card for the life of the tab.
`useSubagentProgress` does both halves: it reads the invocation's progress and
enrols its key, so every route into the family shares the one cleanup
boundary. The panel and the parent card both read through it now.
* 🧽 fix: Free a Read-Created Progress Atom at Its Own Card's Unmount
Enrolling read-created keys in the drain registry only helps where something
runs the drain, and `/search` is a standalone route that never mounts the chat
event handlers. Scrolling a virtualised result list therefore kept minting
members nothing would ever free.
`useSubagentProgress` cleans up after itself instead: on unmount it frees the
family members when the read is the only reason they exist. Two guards keep
that from taking live history with it — a key the stream registered belongs to
the drain, and a member holding folded activity is the record of what the child
did, so reopening its card still shows it.
* 🔗 fix: Free a Progress Atom Only After Its Last Reader Lets Go
Opening a foreground panel before the first event gives one still-empty member
two readers: the card that spawned the child and the panel showing it. Closing
the panel freed it while the card was still subscribed — and a subscriber does
not re-render just because its atom left the family, so the first SSE update
landed on the replacement member and the card's ticker stayed dead.
`useSubagentProgress` counts its mounted readers and frees only when the last
one lets go, alongside the two claims that already blocked it: a key the stream
registered, and a member holding folded activity.
* 🖼️ fix: Stop Reporting a Failed Sandbox Image Read as an Unreadable Format
`read_file` on a `/mnt/data` image collapsed every failure — rate limit,
missing path, truncated transfer, transport error — into the binary-file
hint, whose image branch reads as a permanent capability limit ("is an
image file and cannot be read as text"). The model stopped retrying, and
the operator had no way to tell which failure had actually occurred.
The failure that surfaced it: the reader windows the bytes through
`/exec` stdout, one call per window, against the Code API's per-user
execution limiter (20 requests / 30s in the reference deployment). At a
fixed 32KB window a 122KB chart cost 4 calls and a 1MB image cost 33 —
more than a whole limiter window, so anything over ~640KB could never
complete. A turn that generates several charts and reads them back
exhausts the budget partway through and reports the 429s as unreadable
images.
- `handlers.ts`: failed reads name the real cause and the affordance that
matches it — rate-limited waits and retries, a missing path lists the
directory, a truncated transfer retries. The "cannot be read as text"
phrasing is now reserved for bytes that are not a supported image. An
image past the inline budget says to downscale and read the smaller
copy rather than pointing at `bash_tool`, which cannot show an image.
- `process.js`: the window is derived from the runner's stdout budget
(48,960B vs 32,768B, so a 122KB chart is 3 calls and 1MB is 22), halves
and re-reads the same offset when a runner truncates anyway (remembered
per Code API, with the env remedy logged), waits out a rate limit it
can afford instead of discarding the bytes already pulled, and stops at
a 24-call ceiling so no read stalls a turn across limiter windows.
- `utils/code.ts`: shared `getCodeApiRetryAfterMs` (header, then the
`retry_after_seconds` body); `skillFiles.ts` drops its private copy.
* ♻️ refactor: Move the Sandbox Image Reader Into TypeScript
Addresses the review round on #15453.
- P1: windowing, window sizing, the in-sandbox reader script, response
parsing and byte assembly move to `packages/api/src/files/code/image.ts`,
and the Code API rate-limit policy to `packages/api/src/utils/code.ts`.
`process.js` keeps only the `/exec` transport it owns. Both new modules
are tested against their real implementations (19 + 13 cases), including
the round-trip ceiling, the changed-file guard and the shell-injection
guard on the reader script.
- P2: a configured stdout budget below the old 8KB window floor produced a
window the runner could never emit, and narrowing was pinned to the same
floor, so no retry could succeed. The window now aligns to the base64
group size instead, and the round-trip ceiling bounds what a small budget
costs.
- P2: `.env.example` documented a 32,768-byte default that no longer holds
and never mentioned the stdout budget. It now describes
`LIBRECHAT_CODE_SANDBOX_OUTPUT_MAX_SIZE` as the setting to tune, with the
chunk override as the escape hatch.
- P3: `process.spec.js` no longer reimplements the retry parser in its
module mock. Behaviour is tested where it lives; the mock is a declared
passthrough and the spec covers what the transport still owns — session
forwarding, the profile header, parser hand-off and error logging.
- P3: `getCodeApiRetryAfterMs` reads the response body through `in`
narrowing rather than an `as` assertion.
- P3: the window-sizing JSDoc no longer claims a multiple of 3 in the one
case that is not — an explicit `LIBRECHAT_CODE_IMAGE_CHUNK_BYTES`.
* 🎯 fix: Size Sandbox Image Reads to What the Limiter Can Deliver
Addresses review round 2 on #15453.
- Narrowing now halves the caller's own failing window instead of the
shared learned value, and the learned value only moves down to the
narrowest size any read needed. Reads run concurrently (one per tool
call), so two reads failing at the same size were compounding into a
window two steps smaller than the runner would have accepted, and
persisting it for every later read.
- Narrowing continues until a runner accepts a window or a floor below
which no runner could serve an image at all. Two halvings stopped at
12,240 bytes — still ~16KB of base64 — so an 8-10KB stdout cap that was
not configured up front stayed unreachable.
- The round-trip ceiling is now one limiter window (20), and a read that
cannot finish within it says so from the FIRST response rather than
spending the whole budget rediscovering it: the first window reveals
both the file size and what a call really delivers. A near-limit image
no longer drains the turn's executions before failing, which is what
made the wait budget look too small.
- The round-trip message names the size this deployment can actually
inline, so the model has a downscale target instead of a guess.
- `python3: not found` from the sandbox reader was matching the generic
"not found" in `isSandboxMissingFileError` and being reported as a
missing image path, sending the model to `ls /mnt/data` while hiding a
runner dependency. Image reads now classify only path-specific ENOENT
forms as a missing file.
* 📐 fix: Size a Truncated Read's Retry From the Cap It Revealed
Addresses review round 3 on #15453.
A ~1KB sandbox stdout cap is a real runner default, and the 1,536-byte
narrowing floor sat above it: discovery stopped one step short and
declared every image unreadable, even though small ones fit comfortably
in the 576-byte window the configured path already derives.
Narrowing now runs until no smaller window exists. It also no longer has
to grope its way down: a truncated response emitted exactly as much as
the runner allows, so its length measures the cap this deployment never
declared, and the retry is derived from it directly — one round-trip
instead of the eight blind halvings it takes to fall from ~49KB to ~1KB.
Blind halving remains the fallback and bounds the result either way, so
every retry is strictly smaller than the window that just failed.
* 🗂️ fix: Resolve Code Interpreter Destination Collisions
Codeapi mounts each `/exec` input at a destination derived from its `name`
and rejects the whole request when two entries land on one. LibreChat never
enforced that: `primeFiles` sent `name: file.filename` verbatim, and the
graph seed deduped by `(storage_session_id, id)` — identity, not destination.
Two conversation files sharing a filename therefore killed code execution for
the rest of the conversation. The rejected request never reaches the sandbox,
so no result comes back to collapse the pair, and every later turn re-primes
both and fails identically. Only code-generated outputs are covered by the
`(filename, conversationId, context, tenantId)` partial unique index; uploads
carry `context: message_attachment`, so one conversation can hold several
records sharing a filename — two uploads of `image.png`, or an upload whose
name a later execution wrote back in place.
`packages/api/src/files/code/destinations.ts` now owns the name → destination
mapping for every contributor to an `/exec` file list, mirroring codeapi's
conflict rule including directory-prefix conflicts:
- `primeFiles` claims per pushed file, disambiguating with a `-2`, `-3`
counter and echoing the resolved path into the tool context, so the model
is told where each file actually mounts. Claim order comes from immutable
`createdAt`, not `getFiles`'s `updatedAt` sort, which usage accounting and
re-upload both bump — order-dependent destinations would silently repoint
a path an earlier turn had already handed the model. Newest wins the bare
name, matching `ToolNode.updateCodeSession` and giving an in-place rewrite
precedence over the original it superseded.
- `seedCodeFilesIntoSessions` drops a later file whose destination is already
claimed. Renaming there would invent a path nothing told the model about,
and a conflict at that layer means one logical file arrived twice under
different storage pointers.
Fixes#15443
* 🧹 chore: Tolerate Holes in the Destination Priority Sort
`primeFiles` sorts the raw `getFiles` result before its own per-entry guard
runs, so the comparator has to survive a null row rather than throw ahead of
the loop that was already defending against one.
Also tightens the tool-context assertion in the upload-vs-output case, which
was passing on a trailing space rather than on the path.
* 🔁 fix: Address Codex Review on Destination Assignment
Four findings from the review of `b0f61d0`.
**Identity-derived suffixes instead of a collision counter.** A counter is
assigned from whatever is in the set, so a third file arriving under the
literal name a displaced file had been given pushed that file along, and code
the model wrote in an earlier turn would silently start reading the newcomer.
The fallback now hashes the file's own `file_id`, so a displaced file keeps
its destination for the life of the conversation and only the winner of the
bare name can change. A trailing counter still guards a hash collision so the
search terminates on any input.
**Rank by last content write, not record creation.** `processCodeOutput`
claims one row per `(filename, conversationId)` and rewrites it in place, so
a repeatedly written output keeps its original `createdAt` while recording the
latest writer in `metadata.sourceDispatchedAt`. Ranking on `createdAt` alone
handed the bare path to an upload the output had since been rewritten over.
Recency is now `max(sourceDispatchedAt, createdAt)` — still never `updatedAt`,
which usage accounting bumps without any content changing.
**Advertise a displaced generated output.** Generated files are left out of
the tool context because the model already knows what it wrote — which stops
being true once a newer same-named file takes the bare path and the output
mounts somewhere the model has never seen. Displaced outputs are now listed
with the name they were written as, and displaced uploads name their original
too.
**Rank conversation files above an agent's private ones.** Each agent claims
destinations over its own candidate set — the conversation's files plus its
own — so a private file taking a bare name from a shared file in one agent but
not in another left two agents advertising different paths for the same file
into one shared mount namespace. Shared files now rank first, so the majority
that every agent sees resolves identically. The private-versus-private case
still drops at the merge and is documented there; closing it needs one
assignment across contributors, made before any agent renders its context.
* 📌 test: Pin Alias Ownership on an In-Place Rewrite
Codex round 2 flagged that the identity alias still falls back to a counter
when the alias itself is literally claimed, so a displaced file can move after
all. The mechanism is real and my JSDoc overstated the guarantee, which this
corrects.
The behaviour stays as it is. The realistic way a file arrives under another
file's alias is the model rewriting the displaced file in place: it was told
`<stem>-<hash>.ext`, wrote back to it, and `processCodeOutput` registered an
output under that literal name. Keeping the alias with the newest holder is
what makes the model's familiar path resolve to its own edit; reserving it
against the newcomer would hand that path back to the bytes it replaced. The
test pins that ordering so a later change cannot invert it silently.
* 🩹 fix: Stop the Subagent Composer Unmounting, and Give It Main Chat's Shape
Measured with react-scan and a DOM presence probe against the live panel:
every external delivery unmounted and remounted the composer inside 10ms,
taking focus and any half-typed steer with it.
- The composer stays mounted across a delivery. A delivery re-keys the
thread query to its new task and the task view blanks for the render or
two that takes — deliberately, so task-scoped fields are never
misattributed — but presence followed it down. The last mode the thread
showed now carries the surface across that gap, holding submission until
the new task's own view lands. `dispatched` also counts as live, so a run
that has only just started no longer withdraws the field either.
- One control, not three labels. Submitting IS the steer; with nothing to
send the send button becomes main chat's Stop, which cancels the task.
Queue and interrupt keep the chords main chat gives them
(⌘/Ctrl+Enter, ⌥/Alt+Enter) instead of spelling themselves out beside
the field, and every control says what it is through its tooltip and
accessible name rather than a word label.
- The two composers line up. The field takes `ChatForm`'s own metrics and
the footer clears the viewport floor by the height of main chat's
disclaimer, so both textareas now measure top 805 / height 52 and both
surfaces end at 910 in a 950px viewport.
- The header is main chat's header: a 52px bar that floats over the thread
and fades into it, so the conversation scrolls under it instead of
starting below a solid bordered bar.
Residual re-renders are the per-second timestamp and elapsed tickers plus
the 2s poll both queries run while a child is live — shared with main chat,
about 2ms of render time across a 14s window, and left alone.
* 🎛️ fix: Bind the Chord to Its Own Submission, and Keep Queue Reachable
Codex and Copilot, round one.
- A refused chord no longer decides a later click. `Composer` hands the
submitting event to its host, and the panel keeps the resolved control
bound to THAT event — a ⌘/Ctrl or ⌥ chord the composer then refuses
(empty field, settling, a command in flight) leaves nothing behind for
the next pointer submission to pick up.
- The control comes from the reader's own key policy, not from raw
modifiers. With Enter-to-send off, ⌘/Ctrl+Enter IS the submit chord, so
reading modifiers directly made steering unreachable; the verdict from
`resolveComposerKeyDown` decides instead.
- Queue and interrupt keep a pointer. Chords alone stranded touch readers,
and anyone whose shortcuts are disabled, rebound, or yielded. They are
back as icon-only controls that say what they are through their tooltip
and accessible name rather than a word label.
- Stop cannot render unlabelled. Handler and label travel as one value
(`ComposerStopProps`), so the type refuses a Stop without a name.
* 🔗 refactor: Hang the Panel's Alternate Submissions Off One Shared Send Control
Queue and interrupt had no pointer, then briefly had controls of their own
beside the field — which repeats what submitting already does. Main chat
never did that: it hangs its during-run actions off the send button.
- `SendActions` moves to `@librechat/client`: the hovercard, the rows, the
chord chips and their classes, lifted out of `DuringRunSendButton`
unchanged. Each host passes its own anchor whole, so main chat keeps its
ref (Enter's synthetic click routes through it), its submit type, and its
identifying attributes. Its 13 existing tests still cover the rows.
- The panel offers steer, queue and interrupt from that same control, and
advertises a chord only while it still reaches its action — each hint is
read from the decision table that will execute it, so a rebound, yielded
or disabled chord advertises nothing.
- The send control names what IT does (`com_ui_steer_send`) as distinct
from the `Steer` row it offers, exactly as main chat pairs them.
Two hosts now share one implementation, which is what the seam wanted.
* 🧹 chore: Sort Panel Imports and Drop an Unrelated Reorder
The import sort ran before the last edits to this file. Also reverts a
Tailwind class reorder `eslint --fix` made to `MultiSearch`, which this
change has no business touching.
* 🛡️ fix: Only Offer Controls a Dispatched Task Can Actually Take
Codex, round two.
- A dispatched task is controllable only once the server can address it.
`control.ts` answers 404 when the task has no durable input row and no
live lease, which this panel reads as an inaccessible task and closes its
controls for good — so treating every dispatched task as controllable
could brick them. The field still stays (withdrawing it as a run starts
is the swap this panel exists to avoid); submission waits for evidence.
A task whose controls are definitively closed holds nothing.
- Semantic status roles replace `text-amber-500`, `text-cyan-500` and
`text-red-500` in the action rows — in main chat's list too, since both
now render through the same module.
- One popup over the send control. With actions to offer, the tooltip is
withheld: both attached to the same button, opened on the same focus,
above the same point, and the tooltip's higher z-index covered the list.
- Where the pointer cannot hover, the alternate submissions are controls of
their own: a tap on the hovercard anchor submits, so touch readers could
not reach queue or interrupt at all.
* 🚪 fix: Send Every Control Through the Same Addressability Gate
Codex, round three — both findings were doors around the gate added last
round.
- Stop and the inline actions now answer to `controlAvailable`, not just to
`composerMode`. A retained surface over a dispatched task the server
cannot address yet still offered Stop, and the touch-side queue and
interrupt buttons were live too; each is a command, and each 404 closes
this task's controls for good.
- A trapped panel keeps its actions inside itself. At mobile width with a
hover-capable pointer the list still hung off the send control, portaled
outside the `aside` the focus trap knows — so Tab never reached it. The
actions come inline whenever the panel is a modal, hover or not.
* 🛰️ ci: Publish Every Image Through One Native-ARM Workflow
#15441 removed QEMU from the dev-branch image build and #15444 fixed the
prefix-glob bug it shipped with. Both changes lived in one of five workflows
that build images the same way; the other four still emulate arm64 with no
layer cache and take 20-40 minutes.
Rather than paste the pattern four more times, the build/merge logic moves to a
reusable `docker-publish.yml` that every image workflow calls. #15444 is the
argument for this: one wrong artifact-name expression would otherwise have
needed correcting in five files, and the same prefix hazard exists in all of
them (`librechat`/`librechat-api`, `librechat-dev`/`librechat-dev-api`,
`lc-dev-staging`/`lc-dev-staging-api`). The shared implementation is the
dev-branch one that already ran green, generalised only where callers differ.
Callers pass what actually varies:
- `images` — the target/file/image_name triples
- `tag_suffixes` — newline-separated tags applied in both registries
- `checkout_ref` / `build_branch` — main-image-workflow builds `main`, not the
dispatch ref
`main-image-workflow` and `tag-images` resolve their tags from git history, so
each grew a small `resolve-tag(s)` job whose output feeds the publish. That also
removes a duplicated `git fetch --tags` that previously ran once per matrix leg.
Two details worth noting:
- The digest-count assertion now derives its expected value from the `arches`
input rather than a hard-coded 2, so the architecture list has a single
source of truth shared by the build matrix and the merge guard.
- Nothing is interpolated into a `run:` block any more; `build_branch` and the
build digest arrive through `env`, so a ref name cannot reach a shell.
Net 135 lines lighter, and QEMU no longer appears anywhere in .github/workflows.
Workflow names are unchanged, so retry-docker-builds.yml still matches all five.
* 🔗 fix: Pin Release Builds to One Commit and Survive Full Re-runs
Review findings on the reusable publish workflow.
**P1 — every build leg could resolve `main` separately.** `main-image-workflow`
passed the symbolic ref `main` as `checkout_ref`, so the four build jobs each
resolved it at whatever moment they were scheduled. If `main` advanced in
between, the amd64 and arm64 halves of a release — or the API and application
images — could be built from different commits and published under the same
release and `latest` tags. `resolve-tag` now exports the commit it resolved the
tag from, and the publish pins to that SHA. The single-job workflow this
replaced checked out once, so this was a regression introduced by the split.
`docker-publish` likewise now falls back to `github.sha` rather than passing an
empty `ref` to `actions/checkout`, so callers that omit `checkout_ref` also get
an immutable commit instead of relying on checkout's empty-ref handling.
**P2 — digest artifacts on a full re-run.** `upload-artifact@v4` will not
upload over an existing artifact name, and a full re-run keeps the run id, so a
retry would fail before the merge could run. The suggested fix was to qualify
the artifact name with `run_attempt`, but `retry-docker-builds` picks its
endpoint by conclusion: `rerun` only when a job was cancelled, and
`rerun-failed-jobs` otherwise. Under the latter the merge re-runs alone and must
still find digests uploaded by the *previous* attempt's build legs, which a
run_attempt-qualified name would hide — precisely the shape of the #15444
failure, where the builds passed and only the merge failed. `overwrite: true`
resolves the conflict while keeping names stable across attempts.
**Unreachable error branch.** `LATEST_TAG=$(git tag ... | grep ... | head -1)`
under `set -euo pipefail` exits on grep's non-match, so the "No stable v<semver>
tag found" message could never print. Added `|| true`, matching what
`tag-images` already does. Pre-existing, carried over verbatim in the split.
* fix(agents): check skill version in codeEnvRef cache-hit path
When a SKILL.md body is edited, `updateSkill` bumps `Skill.version`
but does not clear the `codeEnvRef` on bundled skill files. The
cache-hit path in `primeSkillFiles` reused those stale refs without
comparing versions, causing Code API to return 403 ("Unauthorized file
reference") because the session key no longer matched.
Add a version check to the cache-hit guard: a ref whose version does
not match the current skill version is treated as a cache miss, forcing
a fresh upload under the new session key.
Closes#15275
* fix(agents): apply version check to aggregate cache path in primeInvokedSkills
The previous commit added a version check to the per-skill cache-hit
path in primeSkillFiles. Codex review pointed out that
primeInvokedSkills has its own aggregate cache-hit branch that returns
cached refs before delegating to primeSkillFiles. That branch checked
ref presence and session activity but not ref.version against
skill.version, so a stale ref from an older skill revision would still
bypass the guard.
Add the same version comparison to the aggregate filter and include the
skill object in the allResolved entries so the version is accessible.
Addresses Codex review on #15413
* fix(agents): type skill cache version checks
---------
Co-authored-by: dymux <putramkti@users.noreply.github.com>
Co-authored-by: Danny Avila <danny@librechat.ai>
The first native-ARM run published `lc-dev-api` correctly but failed merging
`lc-dev`:
Merging 4 platform digests: 18f83e4a... b4700f27... ca747c51... edf23a05...
ERROR: ghcr.io/danny-avila/lc-dev@sha256:ca747c51...: not found
`lc-dev` is a prefix of `lc-dev-api`, so the merge job's
`pattern: digests-lc-dev-*` matched all four uploaded artifacts — both images'
digests — and then tried to resolve an API digest against the app repository.
`lc-dev-api` was unaffected because no other image name prefixes it.
Two changes:
- Artifact names carry an explicit `-arch-` separator, so one image's pattern
can no longer reach another's digests.
- The merge asserts an exact digest count rather than merely rejecting zero.
The old guard only caught an empty set, which is why four sailed through. Too
few digests would publish a manifest missing an architecture; too many means
the glob crossed images. Either is now a hard failure before anything is
tagged.
No bad manifest was published: `imagetools create` failed while resolving its
sources, so `lc-dev` kept pointing at its previous build. The run also confirms
the approach itself works — `lc-dev-api` merged to a proper index carrying
linux/amd64 and linux/arm64, and the native arm64 legs built in 3-4 minutes
against 13+ minutes under QEMU.
