* 🛟 fix: Keep Loaded Message Content When a Resume Snapshot Is Empty
The sync handler guarded on `data.resumeState?.aggregatedContent` and then
assigned it unconditionally. An empty array is truthy, so a resume snapshot
carrying no content overwrote the content the messages query had already
loaded, leaving the message rendering as a bare cursor with no way to recover.
Treat an empty snapshot as non-authoritative: keep the loaded content and let
live deltas take over. A snapshot that carries content still wins, unchanged.
This is defense in depth rather than a root cause. A resume snapshot goes empty
when the conversation's job is replaced mid-flight (#14348) — because
`streamId === conversationId`, a second submission calls `createJob` on the same
key while the first run is still streaming. With this change that failure
degrades to stale-but-visible instead of destroying content already on screen.
* 🔒 fix: Scope Resume Content Preservation to Identity-Matched Responses
Codex P2: on a regenerate reload before the new run aggregated anything, the
server reports an empty snapshot under a response id not yet in the loaded
history. The parent-based fallback then lands on the answer being REPLACED, and
preserving its content seeded `syncStepMessage` with the stale response, so the
regenerated run's deltas appended to it instead of starting blank.
Preserve loaded content only when the row was matched by the server's declared
`responseMessageId` — the sole case proving the row belongs to this generation.
A fallback-matched row keeps the previous clear-on-empty behavior.
* 🧱 fix: Only Preserve Resume Content When the Row Actually Has Parts
A matched row with no `content` array would have been assigned `undefined`
instead of the snapshot's array. `MultiMessage` branches on `message.content`
truthiness to pick its renderer, and `[]` is truthy while `undefined` is not, so
that would have silently switched a streaming row from the content-parts
renderer to the text one.
Preserve only when the loaded row has a non-empty content array — the case the
guard exists for. Narrows the divergence from prior behavior further: it now
applies solely when there is real content to protect.
* 📌 fix: Pin Scroll-to-Bottom Rib in Message Nav
Render the terminus rib outside the scrolling rail, between the column
and the down chevron, so the scroll-to-bottom affordance stays in view
no matter how far the rail has scrolled.
- scrubTo enumerates ribs from the nav so drag-to-bottom still lands on
the terminus
- the pinned rib drives the shared preview itself on hover and focus,
since it is no longer covered by the column's pointer magnification
* 🖱️ fix: Keep Drag-Scrub Startable From the Pinned Terminus
Pointer-down on the pinned rib no longer reaches the column's handler now
that it renders outside the scrollport, so wire the same drag-start to the
wrapper. Dragging up from the bottom dot scrubs the thread again.
* 🧵 feat: Native Background Execution for Code Interpreter Tools
* 🩹 fix: Address Codex Round 1 (fallback dedupe, harvest failure, handle parsing)
* 🩹 fix: Live Completion Marker + Unkeyed Attachment Dedupe (Codex Round 2)
* 🎨 chore: Sort Imports + Widen Marker Type Comparison (CI)
* 🩹 fix: Stale-Harvest Guard, Error Marker Status, Faster Anchor Retry (Codex Round 3)
* 🧹 refactor: TS Harvest Module, Claim-Neutral Timestamps, Error Parity (Codex Round 4)
* 🩹 fix: Dispatch-Ordered Stale Guard, Foreground Downgrade, Error Wrapper Parity (Codex Round 5)
* 🩹 fix: Retry Past Unfinished Rows + Per-Call Attachment Dedupe (Codex Round 6)
* 🩹 fix: Writer-Dispatch Ordering, Scoped Live Upserts, Reaped-Task Wrapper (Codex Round 7)
* 🩹 fix: Wildcard toolCallId Matching for Bare Attachment Updates (CI)
* 🩹 fix: Claim-Insert Dispatch Stamp (Schema-Backed) + Scoped Status Markers (Codex Round 8)
* 🩹 fix: Pre-Write Ownership CAS + Agent-Scoped Part Patching (Codex Round 9)
* 🩹 fix: Insert-Path Ownership CAS + Agent-Routed Attachments (Codex Round 10)
* 🩹 fix: Agent-Scoped Marker Ids and Attachment Dedupe (Codex Round 11)
* 🩹 fix: Atomic File Commit and Sibling Preview Fan-Out (Codex Round 12)
- Replace the two-step claim-confirm CAS with an atomic conditional updateFile: the ownership predicate (no sourceDispatchedAt, or <= this write's dispatch order) moves into the update filter, removing confirmCodeFileOwnership and the lost-update window between check and write
- Thread agentId through createDownloadFallback so fallback download rows scope to the emitting agent like primary rows
- Fan terminal preview overlays out to every live attachment sharing the file_id in useAttachmentPreviewSync (sibling tool calls no longer stick on pending)
- Restore background artifacts through toStoredArtifact so the size bound applies on re-anchor
- Apply filterAttachmentsForPart to grouped tool-call attachments in ContentParts so handoff agents with colliding provider call ids do not cross-contaminate groups
* 🩹 fix: Agent-Scoped Live Upserts and Monotonic Dispatch Stamps (Codex Round 13)
- Scope the SSE attachment upsert and the useAttachments DB/live merge by agentId with the same wildcard semantics as toolCallId: distinct non-null agentIds stay separate entries, so handoff agents sharing a claimed file_id and a repeated provider tool id (call_0) no longer merge over each other's cards
- Extend the attachment identity key to fileKey::toolCallId::agentId and register less-specific key variants so bare and agent-less live records still dedupe after overlay
- Stamp background task createdAt from a strictly-increasing per-process dispatch counter: raw Date.now() can tie for same-millisecond dispatches and the stale-output guard accepts equal stamps (needed for idempotent re-commits), which would let an older task overwrite a newer task's committed file
Google rejects a YouTube video it cannot ingest with a generic
`400 INVALID_ARGUMENT` that names no cause, which LibreChat relayed
verbatim. Attribute the failure using request context instead: when a
Google/Vertex turn carried an injected YouTube video part and the
provider returns that generic rejection, map it to a typed error the
client localizes.
Verified against the live API: a public 9h15m video is refused this way
on gemini-2.5-flash, 3.5-flash, 3.5-flash-lite and 3.6-flash, including
at MEDIA_RESOLUTION_LOW, while a short video with an identical payload
succeeds. Duration is the dominant trigger; region and access
restrictions return the same response, so the copy leads with length
without overclaiming.
A duration preflight was evaluated and skipped: oEmbed does not expose
duration, leaving only watch-page scraping — a blocking call against
undocumented markup from rate-limited datacenter IPs that would fail
open and still need this mapping underneath.
* 🪟 perf: Virtualize Search Results and Stop the Per-Query Remount
* 🔧 fix: Type-safe globalThis cast in Search route test
* 🔑 fix: Stabilize Search Row Keys and Harden Virtualized Result Edges
Address Codex review findings on the virtualized search results view:
- Key rows by messageId (outer React key + CellMeasurer + cache keyMapper all
aligned) so React reconciles by message, not scroll slot.
- Compare title and conversationId in areSearchMessagePropsEqual so a rename or
refetch that keeps text/id intact still re-renders the row.
- Recompute cached heights on same-length content changes (file previews
resolving, refetch) and on font-size changes.
- Keep the aria-live announcement on the empty-results branch.
- Don't paginate the outgoing query while the user is still typing.
- Show the spinner during the initial debounce instead of a blank route.
* 🧵 fix: Reset Scroll, Remeasure Growth, and Footer-Pad Virtualized Search
Address the second Codex round on the virtualized search results view:
- Reset the List scroll to the top on a new query (results stay mounted via
keepPreviousData, so the List otherwise keeps the previous scrollTop and can
open a new search mid-list); a font-size change keeps the user's place.
- Re-measure a row when its content later grows/shrinks (tool/code output
expands, a late image loads) via a ResizeObserver that clears just that row's
cached height and recomputes from it.
- Give the load-more throttle trailing:false and cancel it when the query
changes, so a queued fetch can't page a stale search.
- Add a fixed trailing spacer row so the last result clears the bottom
gradient/spinner overlay.
* 🫥 fix: Gate Stale Search Results on Refetch State, Not Just Typing
Address the third Codex round: `isTyping` clears when the debounce publishes the
new query, but `keepPreviousData` keeps the old pages mounted until the new
request lands, leaving a window the typing-only guards missed.
- Derive `showingStale = isTyping || isPreviousData` and gate both the dimming
and pagination on it, so the outgoing results stay dimmed and don't page while
the new query is still fetching.
- Compare `unfinished` in areSearchMessagePropsEqual so a finish/cancel that
changes only that flag re-renders SearchContent's incomplete-response notice.
* 📐 fix: Invalidate Row Height Against the Cache and Compare clientTimestamp
Address the fourth Codex round on virtualized search:
- Compare each ResizeObserver height against the cached row height instead of
skipping the first callback, so a cached/fast-loading image that is already
taller than CellMeasurer's mount measurement still invalidates the stale
height (no more overlap/clipping of following rows).
- Compare clientTimestamp in areSearchMessagePropsEqual, since the row timestamp
falls back to it when createdAt is absent.
* 🕳️ fix: Spinner Over False Nothing-Found for Stale Empty Search Data
Address the fifth Codex round: when the previous search had zero matches,
keepPreviousData holds those empty pages (isPreviousData, isLoading false)
during the new request, so the loading gate missed it and flashed a false
"nothing found". Gate the spinner on `showingStale` too, not just isLoading/
isTyping.
* 🔗 fix: Preserve resource owner access when sharing (key share diff by stable id)
The share dialog diff (GenericGrantAccessDialog.handleSave) keyed added/removed
principals by `idOnTheSource`, which is inconsistent for the same user across
sources: getResourcePermissions returns `userInfo.idOnTheSource || _id` (the
external oid for OpenID/Entra users) while the people-picker returns the local
`_id`. The resource owner then appears in both `updated` and `removed`, and — since
updateResourcePermissions applies grants (upsert) before revocations (delete) — the
owner's own ACL entry is deleted when they add anyone to the share list. They then
get 403 on GET/edit/re-sharing their own resource.
Extract the diff into a pure computeShareChanges() helper keyed by
`id ?? idOnTheSource` (stable local id when present, external oid fallback for
principals not yet synced locally, e.g. unsynced Entra groups/users). Add unit tests.
Not reproducible with local-only users, where idOnTheSource falls back to _id and
both sources agree.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* 🔧 fix: address review — dedupe share diff by principalKey; drop test assertion
- computeShareChanges now diffs over the de-duplicated map values, so a principal
that appears more than once in the input (possible while the add/dedupe path still
keys on idOnTheSource) is never emitted multiple times in updated/removed.
- Drop the `as TPrincipal` assertion in the test helper — the literal is structurally
compatible with TPrincipal, so TypeScript validates the shape directly.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
* ⚡ feat: Add Gemini 3.6 Flash and Gemini 3.5 Flash-Lite Support
Adds first-class support for Google's Gemini 3.6 Flash (`gemini-3.6-flash`)
and Gemini 3.5 Flash-Lite (`gemini-3.5-flash-lite`) for both the Gemini API
(AI Studio) and Google Cloud/Vertex integrations.
- Context window (1M) in googleModels; API + cache pricing in tx.ts.
- Model dropdown (config.ts) and GOOGLE_MODELS examples for both integrations.
- Generalize the Gemini 3.5 Flash overrides into a flash-family handler that
strips deprecated temperature/topP/topK and applies each model's default
thinking level (3.6 Flash: medium, 3.5 Flash-Lite: minimal), with
longest-prefix resolution so flash-lite does not collide with flash.
Ref: https://ai.google.dev/gemini-api/docs/latest-model#api-changes-and-parameter-updates
* 🩹 fix: Strip unsupported penalty params for Gemini Flash family
Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash reject presencePenalty/
frequencyPenalty with HTTP 400 ("Penalty is not enabled for this model",
verified live). These pass through llmConfig via knownGoogleParams, so add
them to the flash-family strip list alongside the deprecated sampling params.
* 🩹 fix: Strip Flash-blocked params on custom Google endpoint path
For custom OpenAI-compatible endpoints with defaultParamsEndpoint=google,
getOpenAIConfig strips Flash-blocked params via getGoogleConfig but then
transformToOpenAIConfig re-applies raw addParams, undoing the strip. Filter
addParams through stripGeminiFlashBlockedParams before the transform so the
deprecated sampling / rejected penalty params cannot reach the provider.
* 🔧 chore: Update sharp package to version 0.35.3 in package-lock.json, api/package.json, and packages/api/package.json
* 🔧 chore: Update dependencies in package-lock.json to latest versions for @google/genai (2.13.0), @hono/node-server (1.19.14), fast-uri (3.1.4), hono (4.12.31), and svgo (2.8.3)
* 🔧 chore: Update dependencies in package.json and package-lock.json for @librechat/agents (3.2.67), @opentelemetry/sdk-node (0.221.0), and add new dependencies for @opentelemetry/propagator-jaeger (2.10.0) and protobufjs (7.6.5). Update monaco-editor version in client package.json to 0.56.0.
* 🔧 chore: Upgrade turbo package to version 2.10.5 in package.json and package-lock.json, and update schema reference in turbo.json
* 🩹 fix: Resolve CI breakage from bundled dependency bumps
Not related to the Gemini models — both are fallout from the dep bumps on
this branch:
- monaco-editor 0.56 changed IEditorHoverOptions.enabled from boolean to
'on' | 'off' | 'onKeyboardModifier'; update ArtifactCodeEditor to match
(mirrors the sibling occurrencesHighlight/matchBrackets pattern).
- sharp 0.35.3 fails resize+encode on a degenerate 1x1 PNG (vipspng: libpng
read error); the provider-file e2e fixture was 1x1, so use a 16x16 PNG.
Normal images are unaffected (verified 64x64 resize/encode/jpeg all OK).
* 📝 docs: Correct e2e image-fixture comment (bad IDAT CRC, not a sharp bug)
Root cause was the old 1x1 fixture's corrupt IDAT CRC (verified: IHDR/IEND
CRC OK, IDAT CRC BAD), which sharp 0.35.3's stricter libpng correctly rejects.
Not a dimension/resize edge case and not a sharp bug; comment now reflects that.
An applied steer renders nested inside the response, whose `relative` content
column becomes the steer's offsetParent, so its `offsetTop` is local to that
column rather than measured against the scroll content like top-level rows. The
rail compared that value against `scrollTop`, so once the viewport reached a
steer every jump/current-row decision was computed in the wrong coordinate
space — the "previous" chevron kept re-targeting the steer and got stuck.
- Add `entryTop(el, container)` that sums `offsetTop` up the offsetParent chain
until it leaves the scroll container, folding nested steers back into one
content-space origin (top-level rows collapse to a single hop)
- Use it for the four message-entry measurements (current row, offset cache,
jump previous/next); leave the column-rib offsets untouched
- Guard `getCurrentVisibleId` on a null scroll container
- Test a nested steer (local offset inside a positioned column) lands its rib at
the true thread position; fails with the old single-hop offsetTop
* fix: Use SSE to upload files in order to avoid idle timeouts. Idle timeouts can occur for example from gateways and other services like cloudfare when uploading large files. For example during rag processing the file is uploaded to librechat which then sends it to rag. While librechat is waiting for the embeddings to come back from rag the file upload is sitting idle. Gateways tend to want to cancel the upload with an http 408 , 504, or 524. This change uses SSE to perform the upload so that while librechat is sending the file to rag, it consistently sends back a heartbeat event to the client to keep the connection alive. This is especially useful when utilizing EMBEDDING_BATCH_SIZE in librechat rag which will allow rag to process signifigantly larger files without running out of memory.
* added tests to packages\api\src\files\sse.spec.ts in order to test the new sse.ts
* fix: Harden SSE file upload lifecycle
* style: Sort data provider imports
---------
Co-authored-by: Marc Amick <MarcAmick@jhu.edu>
Co-authored-by: Danny Avila <danny@librechat.ai>
* 🧠 fix: Restore Agent Memory Scope Control in Unified Builder
The Agent Builder redesign (#13952) surfaced memory as a Tools marketplace
item and stopped rendering SidePanel/Agents/Memory.tsx, orphaning the file and
removing the 'Keep memories separate for this agent' control shipped in #14084.
Only the render was lost: the locale keys, memory_scope on AgentForm, the
AgentPanel save path, and AgentSelect hydration all survived, which is why
setting memory_scope directly on the agent document still worked.
Restore it as a builtin item setting (the seam the new builder uses for
per-tool config): mark memory configurable so its row gets a cog, and render a
MemoryConfig branch in BuiltinSection mirroring ArtifactsConfig. Delete the
orphaned component so there is a single source of truth.
Resolves#14287
* 🧹 chore: Remove Orphaned com_agents_enable_memory i18n Key
The key labeled the enable checkbox in the deleted SidePanel/Agents/Memory.tsx.
The unified builder labels the catalog item via com_ui_memory, so it has no
remaining consumer and detect-unused-i18n-keys fails on it.
- Float the in-flight steer stack as a bottom-anchored overlay (`absolute
bottom-full`) so it no longer shrinks the message viewport and older messages
scroll behind it; a per-conversation Jotai height atom reserves an equal band
of bottom padding on the message scroll area so the newest message rests clear
- Collapse long steers to a ~128px preview with a bottom fade and a Show
more/Show less toggle, shown only once the content overflows the cap
- Sticky the per-steer options menu (`sticky top-2`) so it stays reachable while
scrolling through a tall, expanded steer
* 🧬 perf: Memoize Message Spine and Isolate Scroll-Button State
* ✅ test: Pin the message-row memo comparators against field drift
areMessageFieldsEqual and areMessageRowPropsEqual gate every message row's
re-render but had no direct tests. Add a completeness suite: a field-mutation
table asserts each compared field flips the comparator to false (a dropped
field fails its case), plus same-ref / equal-distinct-objects / nullish cases,
and the same shape for the row-props comparator including its delegation into
areMessageFieldsEqual.
* 🎛️ perf: Narrow Composer Subscriptions to Streaming State
* ✅ test: Cover Composer Subscription Refactor's Behavioral Changes
Add regression tests for the previously-uncovered changed behavior in the
composer-subscriptions refactor:
- useLatestMessageMeta: exact projected field set, null on empty cache, and
referential stability + no re-render across token-only cache writes.
- useGetLatestMessage: call-time tail read, stable callback identity with no
re-render on cache writes, Recoil-snapshot sibling-branch resolution, null
with no conversation.
- useSubmitMessage: reads the tail at call time and appends it to root when
missing (and does not when present or absent) — the reconcile branch the
prior test skipped via an early return.
- useHandleKeyUp: ArrowUp in an empty composer clicks the latest message's edit
control, with the null / missing-control / non-empty-composer guards.
- useAskAnswerMode (new spec): liveAsk is projected through the
findLiveAskUserQuestion select, null when empty/disabled.
* 🎨 style: Fix import order in useLatestMessage spec
* 🐛 fix: Dedup retried start-generation requests to prevent duplicate billing
A lost or reset start-generation response makes the client re-POST the
identical payload (up to 3x on network errors). The resumable-stream
controller had no idempotency: createJob unconditionally overwrote the
running job without aborting the prior one, so both requests ran full
LLM completions and both billed while the UI showed only one (#14339).
Add a stable per-submission clientRequestId (uuid, fresh per ask() so a
regenerate differs, reused across the start-generation retries) and an
atomic claim on the job store keyed by userId:clientRequestId. The first
request wins and generates; a retried POST loses the claim and receives
the original stream, which the client subscribes to and replays - no
second billed generation.
- IJobStore.claimIdempotencyKey/releaseIdempotencyKey (in-memory Map+TTL,
Redis single-key SET NX PX + GET Lua, cluster-safe)
- GenerationJobManager.claimGeneration/releaseGeneration (20m TTL)
- Controller claims before the concurrency check, dedups with a resumed
response, releases on start-failure/429
- clientRequestId threaded through TSubmission/TPayload/createPayload
* 🐛 fix: Harden start-generation dedup (Codex review)
Address three P2 findings on the idempotency path:
- Resume replay: a deduped retry now subscribes with resume=true so the
client replays prior content and any pending-action from the running
stream instead of only live events (cross-replica / HITL correctness).
startGeneration returns { streamId, resumed } and the response's
status:'resumed' drives the subscribe mode.
- Wait for the job record: a duplicate that loses the claim now waits
briefly for the winner to create the job before returning the stream
(a stream with no job 404s terminally). If the winner has not
materialized, return 503 SERVER_NOT_READY so the client retries via the
existing readiness path instead of attaching to a dead stream.
- Release only owned claims: track whether the request actually won the
claim; the 429 and init-error paths no longer release a claim owned by
another in-flight generation (fail-open path could erase it and
re-enable double billing).
Adds controller tests covering dedup, the 503 race fallback, win-then-
create, and claim-release ownership on 429 / fail-open.
* 🐛 fix: Don't trap deduped retries on missing job records (Codex review)
The previous round returned 503 SERVER_NOT_READY when a deduped retry's
job record was absent. But a missing job usually means the original
generation already completed and was cleaned up (cleanupOnComplete) — the
correct recovery is to return the stream and let the client's subscribe
404 handler refetch the persisted messages. The 503 instead trapped the
send in a readiness-retry loop until the client's window expired.
Keep the bounded wait (it still covers the job-about-to-be-created race)
but always return the resumed stream afterward; a gone/never-created job
recovers via the client's existing 404 path instead of being treated as
indefinitely starting. Updated the controller test accordingly.
* 🐛 fix: Gate deduped resume on claim age, not just job presence (Codex review)
Removing the 503 entirely (previous round) reintroduced the inverse race:
if the winning request stalls between claimGeneration and createJob, a
losing duplicate saw no job, returned status:'resumed' anyway, and the
client subscribed to a stream that did not exist yet — the 404 handler
tore the turn down while the winner went on to generate and bill with no
UI attached.
Distinguish the two missing-job cases by claim age (claimedAt now travels
on the claim value):
- fresh claim, no job yet → winner is still starting → 503 SERVER_NOT_READY
so the client retries via the readiness path (bounded, not indefinite).
- old claim, no job → the original already completed and was cleaned up
(or the winner died) → attach; the client's 404 handler refetches.
Tests cover both age branches.
* 🐛 fix: Scope dedup fail-open + keep resumed convos on 404 (Codex review)
- Fail-open only on claim acquisition: a store error while checking an
already-confirmed existing claim no longer falls through to createJob
(which would start a second billed generation during a Redis hiccup).
Once claim.existing is known, a job-lookup error returns 503 retry.
- Don't drop a resumed convo on 404: the optimistic-conversation cleanup
in useResumableSSE now runs only for fresh (non-resume) subscribes. A
deduped resume whose original completed and was cleaned up 404s, but its
conversation is persisted and must stay in the sidebar.
Adds a controller test for the job-lookup-error path (503, no createJob).
* 🐛 fix: Reconcile resumed convos on 404 instead of guessing (Codex review)
Round-4's !isResume guard fixed the completed-and-cleaned case (don't drop
a persisted convo) but left the inverse: a new-conversation retry deduped
to a claim whose original worker died before persisting still resumes,
404s, and — with removal skipped — leaves a phantom /c/<streamId> sidebar
entry.
Stop guessing keep-vs-remove on a resume 404. Reconcile against the
server: invalidate the conversations list so a real (persisted) convo
stays and a phantom is dropped. Fresh (non-resume) optimistic streams
still prune immediately. Adds a client test for the resume path.
* 🐛 fix: Finalize failed job before releasing its claim (Codex review)
In the initialization-error catch, the idempotency claim was released
before completeJob(streamId). A racing retry could win the released key
and createJob() the same streamId while this catch was still running, and
completeJob() (not guarded by the original createdAt) would then abort the
replacement. Finalize the failed job first, then release the claim.
Adds a controller test asserting completeJob precedes releaseGeneration.
* 🐛 fix: Clear claims on destroy + survive completeJob failure (Codex review)
- InMemoryJobStore.destroy() now clears the idempotencyClaims map, so a
reused/reconfigured store instance doesn't dedup a fresh start against a
torn-down job's stale claim.
- Init-error cleanup: completeJob() is swallowed so a store-hiccup
rejection can no longer skip the idempotency-key release and the
pending-request decrement (which would wedge the retry behind the claim
and leak the concurrency slot). A failed completeJob finalized nothing,
so releasing afterward still can't abort a later replacement.
Tests: claims cleared on destroy; release + pending decrement still run
when completeJob rejects.
* 🩹 fix: Route configured document types to RAG /text on agent upload
Restores pre-#11900 behavior for 'Upload as Text': when an admin narrows
fileConfig.text.supportedMimeTypes to a non-permissive allowlist that includes
a document type (docx/xlsx/pdf/ods/odt) and a RAG API is configured, the file
is sent to RAG /text instead of the built-in document parser.
The permissive default catch-all is excluded via isPermissiveMimeConfig, so RAG
deployments that never customized text handling keep the built-in parser. When
RAG is unreachable, parseText's new allowNativeFallback:false makes it throw so
the upload falls back to the built-in document parser rather than degrading a
docx/pdf to raw native-text bytes.
Fixes#14245
* style: sort imports in text.spec.ts (CI import-order)
* 🩹 fix: Scope RAG fallback catch to extraction only, not persistence
The configured-text branch wrapped both parseText and createTextFile in the
fallback try, so a persistence failure after a successful RAG extraction (size
guard, db.createFile, agent-resource mutation) was misread as RAG-unavailable
and retried with the built-in document parser, masking the real error and
risking a duplicate agent-resource mutation. Only the RAG extraction is now in
the fallback catch; a persistence failure surfaces as itself.
Addresses Codex P2 on #14345.
* 🔒 fix: Skip revoke for principals also being granted (owner-lockout guard)
bulkUpdateResourcePermissions flushes grants (upserts) before revokes (deletes).
If a principal appears in both updatedPrincipals and revokedPrincipals, the ACL
entry is granted and then immediately deleted, stripping access the caller just
set. This can strip a resource owner's own grant when the share dialog places
the owner in both lists from a client id/idOnTheSource mismatch (OpenID/Entra).
Add a server-side guard: track principals granted in the same request and skip
any revoke for the same principal, so granting wins and owner lockout is
impossible regardless of how the client computes the share diff. Complements the
client-side keying fix in #14317.
Refs #14316
* 🔒 fix: Exclude PUBLIC from grant-wins guard so public-disable is honored
The grant-wins guard must not apply to PrincipalType.PUBLIC. An explicit
public: false disable adds the public principal to the revoke list; a
contradictory payload that also grants public (public in the updated list) would
otherwise skip the revoke and leave the resource public. Disabling public access
must always win. User/group owner-lockout protection is unchanged.
Addresses Codex P2 on #14347.
* 🔒 fix: Move revoke guard inside per-principal try (tolerate malformed entries)
The grant-wins guard read principal.type before the per-principal try/catch, so
a malformed revoke entry (e.g. removed: [null]) would throw out of
bulkUpdateResourcePermissions after grants were already flushed on
non-transactional MongoDB, leaving partial permission changes. Move the guard
inside the try so a malformed entry is recorded in results.errors and skipped,
matching prior behavior.
Addresses Codex P2 on #14347.
Enhance the Vite configuration by including specific node polyfills in the `optimizeDeps` section. This change ensures that the necessary polyfills for `buffer`, `process`, and `global` are optimized for better performance during development. This adjustment aims to improve compatibility and streamline the build process.
When OPENID_REUSE_TOKENS is enabled and both the openidJwt strategy and the
HS256 jwt fallback fail, the final 'Authentication failed after all strategies'
warn log reported only the fallback's reason. For an RS256 provider (Keycloak,
Auth0, Okta) that surfaces as 'invalid algorithm', which is the HS256 fallback
rejecting the provider token, not the real reason openidJwt did not
authenticate, and it was previously only visible at debug level.
Include the captured primary (openidJwt) failure reason and error name in the
final warn log so reused-token failures are diagnosable without enabling debug
and are not misattributed to the fallback.
Refs #14311
* fix: stop agents from over-using the web_search tool
The web_search tool context injected into the agent system prompt was framed action-first ("execute immediately without preface") and never told the model when NOT to search. Models treat this as a default-on signal and search on nearly every turn, across all providers (Anthropic API, OpenRouter, etc.) since this instruction is provider-agnostic.
Reframe the instruction so the default is to answer from the model's own knowledge, gate searching behind a concrete trigger list, and explicitly reject the "a search might return relevant results" rationalization. Citation-format guidance is unchanged.
* refactor: make web_search guidance concise and neutral
Address maintainer feedback to keep the change minimal and generalized. Replace the verbose trigger list with a single neutral sentence: search when the user's request calls for it or when current/external information is required, and otherwise answer directly. Demote "execute immediately without preface" so it applies once a search is warranted rather than as the default, which was being read as "search on every turn."
* ✋ feat: Add Reclaim-Gated Controls to In-Flight Steers
Give a pending steer the same controls as a queued message — edit, convert
to queue, and the during-run mode toggle — instead of only a bare cancel.
Every re-homing action reclaims the steer from the server queue first and
acts only on a confirmed `removed: true`. A steer leaves that queue only by
injecting, so a lost race means the words are already in the run: queueing
or editing them then would say the same thing twice.
- Return a `SteerCancelOutcome` ('reclaimed' | 'applied' | 'failed') from
useSteerCancel so callers can distinguish "the words are still mine" from
"already injected" and "unknown fate" — the last two only toast.
- Extract RowMenu, useDefaultToggleEntry, and the shared button classes into
SteerMenu so both during-run surfaces use one implementation.
- Offer controls only once `pending`: a `sending` steer has no server id to
reclaim with, so its words cannot be held back.
- Pin the control cluster visible while its menu is open — the portaled items
hold focus outside the subtree, so `focus-within` alone would drop it.
* 🩹 fix: Address Codex Findings on Reclaimed-Steer Controls
Route a reclaimed steer through the shared conversion, and stop the async
reclaim from stranding items or clobbering a composer that moved on.
- Queue a reclaimed steer via useSteerConvert instead of enqueue, so it keeps
its original id and createdAt. enqueue minted a fresh v4/Date.now() and
appended, so a steer accepted BEFORE a later follow-up drained after it —
breaking the invariant the leftover-steer path documents.
- Submit the item directly when the run ended during the reclaim round-trip:
the drain consumes its one-shot signal against an empty queue, so nothing
was left to auto-send it. Read run state and conversation from refs, since
the reclaim resolves after the bubble unmounts.
- Refuse the composer restore when the origin conversation no longer matches
or a newer draft is present, and queue the words instead of overwriting
them. Neither text is the one to throw away.
- Split useSteerReclaim (POST only) out of useSteerCancel, so the menu actions
leave the chip alone until the outcome is known while the X stays optimistic.
* 🛡️ fix: Harden Reclaimed-Steer Guards Against Stale State
Both guards from the previous round read values that had moved on by the
time the reclaim resolved.
- Compare the origin conversation against a ref, not the closure. The `.then`
holds `restoreReclaimedSteer` from the render it was clicked in, so its
captured `conversationId` is the OLD chat — the guard compared that against
itself and passed, while `methods` (one form, reused across conversations)
wrote the steer into the chat now on screen.
- Gate the direct send on the drain's own rule. `!isSubmitting` also covers a
Stop or an error, so converting and then pressing Stop auto-sent the text
past useQueueDrain's completed-or-armed-interrupt-only rule. Capture the
run's outcome before the drain consumes the one-shot signal, and send only
on a clean completion of THIS conversation.
* ♻️ refactor: Re-Arm the Drain Instead of Direct-Sending Reclaimed Steers
The direct send was the wrong mechanism: it re-implemented the drain badly,
and each round of review found another rule it had skipped. Delete it and let
useQueueDrain do the sending — it already owns every one of those rules.
- Re-post the spent run-end signal under the conversation instead of calling
sendNow. The drain then applies the completed-only rule, FIFO order (an
older follow-up is no longer skipped), NEW_CONVO migration, and submits via
`ask` — which, unlike the composer's sendNow, does not reset the form and so
cannot wipe a draft typed while the reclaim was in flight.
- No-op when a signal is still armed: that drain has not run yet and will see
the item on its own, so arming a second carrier would send twice.
- Watch the parked run-end too, not just the index one, so a run that ended
while the user was in another chat is still seen.
- Treat staged files, quotes, and skill picks as a draft when deciding whether
a restore may overwrite the composer — editToComposer MERGES into them, so
restoring over staged context would glue two submissions together.
* 🎯 fix: Scope the Re-Arm Suppression to This Conversation
The no-double-arm guard treated ANY armed index run-end as proof the drain
would see this conversation's newly queued item. The index slot is shared:
useQueueDrain parks a foreign signal under its own conversation and then
inspects only the active one's queue, so a reclaimed steer sitting behind an
unrelated run-end would never be looked at and would strand until sent by hand.
Suppress only when the armed index signal belongs to THIS conversation — which
is the case where the drain really will see the item. The parked check was
already conversation-scoped by its key.
* 🧭 fix: Trust the Refs Only While They Describe This Chat
useSteering is reused across conversations, so after a navigation its live
refs describe the NEW chat while the reclaim's callback still speaks for the
old one. Restoring the conversation-identity guard I removed last round, which
was wrong precisely because the refs are live but not conversation-scoped.
- Skip the re-arm entirely once conversationIdRef no longer matches the steer's
conversation. Reading isSubmittingRef there could suppress a needed re-arm,
and lastRunEndRef could hold the NEW chat's run-end — parking that under the
old conversation would make drainNext (which keys off end.conversationId)
drain the wrong queue into the wrong chat.
- Assert lastRunEnd.conversationId matches before re-arming, so the invariant
is enforced where it is relied on rather than inferred from render order.
Nothing is lost by stopping: the item is already queued under its own
conversation, and that run's end parks under it and drains on return.
* 🗝️ fix: Key the Captured Run-End by Conversation
A single run-end slot could only answer for whichever chat was on screen when
a reclaim landed, so the guard had to bail on navigation — stranding a steer
whose run had already completed, contrary to "queue for after the response".
Key the captured run-ends by conversation instead. The stored end always speaks
for the chat the words belong to, so navigating away no longer suppresses the
re-arm, and another chat's end can never be parked under this one (which would
hand drainNext a foreign end.conversationId and drain the wrong queue).
- Drop an entry when its conversation starts another run: a superseded end must
not authorize a drain of the run now in flight. This replaces the isSubmitting
guard, which described the wrong chat after navigation.
- Remove conversationIdRef, now that no read depends on where the user is.
* 🧹 fix: Close Three Reclaim Races Around Answer Mode and Run End
- Refuse the composer restore while answer mode is active. `onSubmit` hands
composer text to `answerMode.submitText` before any send/steer routing, so a
restored steer would become the tool's answer on the next Enter. Read through
a ref: the run can pause on ask_user_question mid-reclaim.
- Skip the restore when a terminal conversion already queued the words. The
chip stays interactive during the reclaim round-trip, so a run ending or
erroring meanwhile converts it — restoring after would leave one copy queued
and another in the draft. The queue action needed no guard; the conversion
already dedupes by id.
- Carry quotes/skill picks on the reclaimed steer itself. The conversion
recovers them from the chip, which a competing X can delete mid-round-trip,
silently dropping the picks.
* 🎛️ feat: Fold Cancel Into an Always-Visible Steer Menu
Make the in-flight steer bubble a single, discoverable affordance instead of
two hover-hidden ones, matching how Codex/ChatGPT present the same control.
- Fold Cancel into the ⋯ menu as an item (X icon), removing the standalone X
button. It keeps the optimistic `useSteerCancel` path — no reclaim gate,
since cancel drops the words rather than re-homing them.
- Show the ⋯ at rest on every pointer instead of hover-gating it. A label-less
menu hidden until hover is undiscoverable on desktop and unreachable on touch;
always-visible also matches the queued rows' controls and drops the
hover/focus/menu-open opacity juggling entirely.
* 🪢 feat: Make Cancel and Queued Trash Non-Destructive
Both removal actions now hand their text back to the composer instead of
dropping it, so a message the user typed is never gone forever.
- In-flight Cancel: before cancelling, restore the words to the composer via
the gated `restoreReclaimedSteer` (skipped once applied — they are already in
the response). The restore refuses on its own rather than clobber a draft,
land in another chat, or fight answer mode; the cancel still runs reliably
either way, so an unwanted steer stays killable.
- Queued Trash: same safety net — thread the gated restore into the queued
rows and return the words (with their carried quotes/skills) to the composer,
then remove either way. Aligns the two surfaces on one behavior.
- Export the shared `RestoreToComposer` type so both surfaces reuse it.
Left the reliable-remove path intact (a steer sometimes must be killed before
it reaches the model) and did NOT reach for a delete+Undo snackbar, which the
shared Toast can't render without a cross-cutting action-button change.
* 🔒 fix: Restore Cancelled Steer Text Only on a Reclaimed Outcome
The cancel safety net restored the words to the composer synchronously, before
the cancel POST resolved. On `applied` (cancel lost the race, steer still
injects) or `failed` (POST errored, chip restored), the same text ended up both
in the run/bubble and in the composer.
Await `cancelSteer`'s outcome and restore ONLY on `reclaimed` — the one result
that proves the steer never reached the run. `applied`/`failed` leave the words
where the events place them, no composer copy. The gated restore still refuses
rather than clobber a draft typed during the round-trip.
* 🧵 fix: Never Drop Cancelled Text; Keep the Steer's Submit Time
Two follow-ups on the cancel safety net.
- Cancel no longer silently drops the words when the reclaim succeeds but the
composer refuses the restore (draft typed, answer mode, navigated). The chip
is already gone, so queue them like Edit does — never lost, just re-homed —
with the same toast.
- Preserve the true submission timestamp across submitSteer's chip states. The
ACK and failure chips reset createdAt to a LATER Date.now(), so a draft queued
during the 202 round-trip could sort ahead of a steer submitted before it and
drain out of order. Capture the submit time once and reuse it for all three.
* 🚪 fix: Refuse Reclaimed-Steer Restore Into an Unmounted Composer
A reclaim/cancel round-trip can resolve after ChatForm unmounts (left the
route, closed the pane). Its refs still hold the origin conversation, so
`restoreReclaimedSteer` passed its checks, wrote into a dead form, and returned
true — making the caller drop the steer instead of queueing it, losing the text.
Track mount state and refuse the restore once unmounted, so the caller queues
the words (recoil is global, so the queued chip survives the navigation).
`RedisEventTransport.emitChunk` awaited `INCR` (sequence allocation) and then
`PUBLISH` as two sequential round trips, per streamed delta. Fold both into one
Lua `EVAL` that allocates the sequence and publishes server-side.
Measured 50.6% reduction on the emit path (0.219ms -> 0.108ms per delta, 2000
deltas, loopback Redis). The saving multiplies by the token count of every
response, and scales with RTT: on setups where Redis sits behind a network
boundary (WSL2 loopback, cross-host, cross-AZ) at ~1-2ms/RTT this is ~0.5-1s on
a 500-token response.
The sequence is spliced into the payload server-side rather than round-tripped
through cjson, which would coerce empty arrays to objects and alter float
precision. The channel is passed as ARGV rather than KEYS: ioredis applies
`keyPrefix` to EVAL keys but never to a pub/sub channel, so keying it would
publish to a prefixed channel no subscriber listens on. PUBLISH is broadcast
cluster-wide rather than slot-routed, so it needs no key for Cluster
correctness.
Also parallelize `getResumeState`'s three independent job-store reads
(`getContentParts` / `getRunSteps` / `peekSteers`), collapsing 3 round trips
into 1 on every resume. Safe despite `readCachedGraph`'s cache-drop side effect:
each call catches its own unusable-graph throw and falls back to durable
reconstruction, so ordering cannot change the result.
`createMockPublisher` gains an `eval` that delegates to its own incr/publish
mocks, keeping the existing error-propagation tests meaningful now that
sequence allocation and publish are one operation.
#14272 gated the hover-revealed "..." button on hover capability, but pinned
agents still take two taps on iOS. That fix was aimed at the wrong mechanism
for this list.
Every favorite row is wrapped by DraggableFavoriteItem, and react-dnd's
HTML5Backend stamps `draggable="true"` on that wrapper unconditionally
(connectDragSource, HTML5BackendImpl.js:101 — `canDrag: false` does not
suppress it, react-dnd#2909). iOS Safari hands a touch on a draggable element
to the drag recognizer rather than synthesizing a click, so the row underneath
only selects on the second tap.
The draggable wrapper is what separates favorites from every other sidebar
row. Conversation rows are more hover-dependent than favorites ever were
(ungated `opacity-0 group-hover:opacity-100` plus an onMouseEnter that mounts
ConvoOptions) and select on the first tap.
Connect the drag source only under `(hover: hover)`. Nothing is lost on touch:
HTML5Backend has no touch support, so drag-to-reorder never worked there.
Passing null to the connector unsubscribes cleanly and resets the attribute,
so a hybrid pointer flipping the query re-arms drag.
* 🔒 fix: Scope, Cap, and De-Execute the In-Flight Steer Stack
Codex review on 9594ee7146. Three valid P2s, all fallout from moving the
steers out of the message region into the composer.
- Run scope: the in-thread slot was gated on `effectiveIsSubmitting`, but
the new one only checked `steering.enabled` (= steerable endpoint +
primary composer), which is true with no run in flight. A chip that
outlives its run — cancel's onError restoring one the final event
already converted to a queued follow-up — stranded a bubble above the
composer, possibly beside the queued row for the same text. Restores
the run gate.
- Height cap: a steer runs to 16k chars (DEFAULT_STEER_MAX_LENGTH) and a
run takes up to 10 (STEER_QUEUE_MAX_DEPTH). Unbounded in the composer,
that pushes the input off-screen; the old slot could grow freely
because it scrolled with the thread. Caps the stack at 35vh.
- Code execution: MarkdownLite defaults `codeExecution` on, but this
bubble renders outside MessageContext, so Run Code would fire the tool
mutation with no messageId and an empty conversationId. Passes
codeExecution={false} — a provisional steer has nothing to run against.
* 📜 fix: Keep the Newest In-Flight Steer in View
Codex review on de9ede2aad. Valid, and a regression from the 35vh cap in
the previous commit: steers append newest-last, so once the stack
overflows it sits scrolled to the OLDEST entry. The steer just submitted
— and its cancel control — lands below the fold and reads as dropped.
The cap traded "composer pushed off-screen" for "newest steer hidden".
Sticks the stack to the bottom, keyed on the newest steer id so it fires
when one is appended rather than on every render.
* 🧹 fix: Don't Restore a Steer That Already Settled
Codex review on 09c93987a. Valid, and it closes the hole the run gate
only hid — I deferred this two rounds ago as pre-existing, which was
wrong: the gate hides a stale entry while the run is idle, but
useQueueDrain auto-sends the queued follow-up, isSubmitting flips back
to true, and the previous run's entry renders as an in-flight bubble
beside its own queued copy.
Fixes it at the source instead: cancel's onError no longer restores a
steer whose id is in appliedSteerIdsByConvoId — the settled set, stamped
by both the apply path and the run-end conversion, and deliberately
capped rather than cleared so it survives run end for exactly this race
(same instrument as #14276).
The run gate stays: it's parity with the in-thread slot's
effectiveIsSubmitting and still defends against any other leak.
* 💬 refactor: Anchor In-Flight Steers Above the Composer
Mid-run steers were rendered in-thread at the tail of the streaming
assistant message, at a guessed injection point, then swapped to the
persisted STEER part at its real index once the server applied them.
In-flight steers now render as message bubbles anchored above the
composer, so the thread only ever shows what the server committed:
- InFlightSteers: sending/pending steers as left-aligned bubbles with
image previews and a cancel affordance, anchored above the composer box
- PendingSteerChips: unchanged, still owns the failed/queued control rows
- SteerPart: drops the pending/onCancel props, now only ever the
server-applied part
- useSteerCancel: the optimistic cancel + restore-on-error, lifted out of
the deleted PendingSteers slot
The steer state machine is untouched: the 202 ACK reconciliation,
reconnect reseeding, and queue conversion all key off status, not render
location.
* 🎨 fix: Match In-Flight Steer Presentation to the Applied Part
Codex review on 6a5f36f7ef. All three findings were real, and all three
were the same underlying mistake: the anchored bubble hand-rolled
presentation instead of reusing the leaves the applied SteerPart uses,
so a steer visibly changed on apply.
- Images: the message `Image` sets an inline height from the file's
dimensions and centers with object-contain, so clipping it into a 56px
wrapper showed the blank top of a large element. Use ImagePreview, the
composer's fixed-size thumbnail path (also gives click-to-enlarge).
- Non-image files: FileContainer always renders a button, so without an
onClick the chip was dead. Wire FilePreviewDialog, as SteerPart does.
- Markdown: honor enableUserMsgMarkdown so text does not reflow the
moment the server injects it.
Splits files in a single pass rather than two filters.
* 🎨 style: Outline the In-Flight Steer Bubble and Move the Bolt Inline
The filled bubble read as a settled message. An outline reads as
provisional, which is what an in-flight steer is, and separates it from
the composer surface behind it.
- Border + bubble keeps the composer's rounded-3xl radius so it reads as
anchored to the input rather than floating over it. Border stays
NEUTRAL: the failed-steer row already owns a colored (red) border, so
a colored outline on the happy path would read as a warning.
- The Zap moves inside the bubble, left of the text, where it prefixes
the words as a status label instead of competing with cancel for the
right edge. items-start pins it to the first line when text wraps.
- Cancel drops plain `opacity-0` for `[@media(hover:hover)]:opacity-0`,
matching SteerPart's info affordance: a hover-revealed control is
unreachable on touch until a first tap (the #14272 pattern).
* 🖼️ feat: Return Sandbox Images From `read_file` as Viewable Artifacts
The code-execution sandbox `read_file` path refused every image
extension because it reads files via `cat` over codeapi's JSON `/exec`
transport, which lossily corrupts non-UTF-8 bytes. The skill-file read
path already surfaced images as artifacts; this brings the sandbox path
to parity so an agent can actually see a chart/screenshot it reads.
- `readSandboxImage` (process.js): a Python base64 reader over `/exec`
with an in-sandbox size guard so oversize images never cross the wire;
base64 is ASCII-safe where `cat` corrupts.
- `handleSandboxImageRead` (handlers.ts): byte-integrity check (guards
against a truncated `/exec` stdout), MIME resolved purely from the
magic-byte sniff (extension only routes; a mislabeled non-image falls
back to the bash hint), and graceful degradation on every failure mode.
- Shared `buildImageArtifactResult` used by both read paths; the result's
`artifact.content` image_url reaches the UI (tool-end callbacks save it
as an attachment) and the LLM (SDK folds it into the model-visible
message for Anthropic/OpenAI/Google).
* ✅ test: Sync read_file code-only description assertions with image wording
* 🛡️ fix: Harden sandbox image reads (regular-file guard, completeness check)
Addresses Codex review on PR #14277:
- readSandboxImage now os.stat's the target and rejects non-regular files
(FIFOs, sockets, /dev/* symlinks) via stat.S_ISREG, and bounds the read at
limit+1 bytes — a device/FIFO can no longer stream unbounded into memory
until the request times out.
- handleSandboxImageRead validates completeness (not just the magic header):
PNG must end with the IEND trailer and WebP's RIFF size must match the byte
length, so a truncated/interrupted image degrades to the bash hint instead
of being sent as a corrupt image_url. JPEG/GIF stay header-level (they can
carry trailing metadata; a strict end-marker would risk false rejections).
* 🩹 fix: Chunk sandbox image reads to fit the runner stdout cap
Inlining any real image failed with "is an image file (.png) and cannot
be read as text". Root cause: readSandboxImage base64-encodes the file to
STDOUT, but the runner caps stdout at SANDBOX_OUTPUT_MAX_SIZE (1024 bytes
by default) and SIGKILLs the job on overflow (status OL), truncating the
JSON mid-base64. The parse then threw and the handler degraded to the
binary hint. The in-sandbox MAX_BINARY_BYTES=5MB guard never fired because
the *transport*, not the file size, is the real ceiling: a 5MB image needs
~6.8MB of stdout. Reproduced against a live MicroVM — a 186KB matplotlib
PNG died with 'stdout length exceeded' at exactly the 65536-byte cap.
Read the file in windows instead: each /exec pulls raw bytes at an
offset and base64s only that slice, so every response stays under the cap
regardless of how the runner is configured; the chunks are reassembled and
verified against the sandbox-reported total. Verified end-to-end on a real
MicroVM: 25KB and 186KB PNGs both round-trip byte-exact (sha256 match).
Also:
- Detect the truncation explicitly (status OL) and name the fixable cause
(chunk size / SANDBOX_OUTPUT_MAX_SIZE) instead of "unexpected output".
- Parse the LAST stdout line so a shell banner can't break the read, and
include a stdout snippet when it genuinely is unparseable.
- LIBRECHAT_CODE_IMAGE_CHUNK_BYTES (default 32KB) tunes the window.
- Tests drive the real reader against a mocked /exec transport rather than
mocking readSandboxImage, which is why the existing suite stayed green
through this bug.
* 🎯 fix: Cap sandbox inline images at 1MB, separate from skill-file reads
The sandbox and skill-file image paths shared MAX_BINARY_BYTES (5MB), but
their transports differ: skill files stream from storage, while sandbox
bytes come back base64 over /exec stdout under the runner's output cap, so
the reader windows the file and cost scales in round-trips (~160 at 5MB vs
~32 at 1MB). Nothing is gained by allowing more — vision providers
downsample to ~1.5-2k px regardless, so multi-MB originals buy no fidelity
while grinding through round-trips.
Give the sandbox path its own MAX_SANDBOX_INLINE_IMAGE_BYTES (1MB), used
for both the read cap and the over-limit message (which previously quoted
5MB while the reader enforced something else). Skill-file reads keep 5MB.
Verified against a live MicroVM: a 186KB PNG round-trips byte-exact, and a
1.4MB file returns tooLarge in a single round-trip with zero bytes
transferred, degrading to the existing bash_tool hint.
Removing the last file from an agent's Context panel fired no request and
the file reappeared on reload.
`FileContext` mounts `FileRow` only while `fileCount > 0`, and
`useFileDeletion` lives inside `FileRow` behind a 1s debounce whose unmount
cleanup called `debouncedDelete.cancel()`. Deleting the last file drops the
count to 0, unmounting `FileRow` and cancelling the delete the user had
already confirmed. Removing a non-last file kept the row mounted and worked,
which made the failure look erratic. The same cancel also dropped deletes in
any panel closed within the debounce window.
Flush the pending batch on unmount instead of cancelling it.
`loadTools` contracts every `requestedTools` entry as `() => Promise<Tool>`
and the loader relies on it via `validTool().catch(...)`.
The `ask_user_question` factory was registered synchronously, and
`createAskUserQuestionTool()` returns a `DynamicStructuredTool` directly, so
the call returned a tool with no `.catch`, throwing
`TypeError: validTool(...).catch is not a function`.
The throw happens inside the loop before `Promise.all`, so it aborted the
entire tool load for the turn, not just this tool: agents with
`ask_user_question` attached ran with no tools at all.
* 🧹 fix: Drop Pending Composer Draft When Steering or Queuing
A during-run submit takes the composer text into a steer or a queued item
and clears the composer via the form's `reset()`. That clear is
programmatic, so it never fires the `input` event `useAutoSave` listens
on, leaving the autosaved draft (keyed under `PENDING_CONVO` for the
duration of the run) behind.
When the run ends, `useAutoSave` migrates a surviving pending draft onto
the real conversation id and restores it into the textarea. The result:
a queued message that was successfully auto-sent by the run-end drain
immediately resurfaced as the composer draft, and persisted there under
the conversation key across reloads.
Consume the pending draft at the three composer-origin entry points
(steer, queue, interrupt & send), mirroring the existing
takeComposerFiles/takeComposerContext consumption helpers. Only a
consumed submit clears it — a refused one (empty text, uploads in
flight) leaves the draft intact.
* 🔒 fix: Flush The Live Composer Value On Debounced Autosave
Codex round 1: the 25ms debounced autosave captured the textarea value at
event time, so a write scheduled just before a during-run steer/queue
could land after the composer was consumed and cleared — rewriting the
just-sent text back into the PENDING_CONVO draft and defeating the clear.
Read the value at flush time instead. When the composer was cleared in
the debounce window the pending write now removes the draft rather than
resurrecting it, and an untouched composer saves exactly as before.
