⬆️ chore: Bump @librechat/agents to v3.6.0

[danny-avila]

Summary

Bumps @librechat/agents from ^3.5.1 to ^3.6.0 in api/package.json and packages/api/package.json, with the matching package-lock.json and bun.lock entries. The existing ^3.5.1 caret cannot cross the minor, so the pin has to move explicitly.

v3.6.0 contains three changes over v3.5.1, all additive:

• fix: Close Subagent Child-Graph Run Steps (agents#417) — subagent child graphs execute via workflow.invoke() outside Run.processStream, so the terminal sweep never reached their run steps and they were left open. They now close on both the success and error paths. This is the piece that makes on_run_step_closed reliable for subagent tool cards, which 🩺 fix: Render Stopped Run Steps From Explicit Status #14871 / 🧩 refactor: Extend Step Status To Remaining Cards; Separate Cancelled From Failed #14873 consume.
• fix: Restore Run Steps Across Process Resumes (agents#419) — open run-step lifecycle state is now persisted in LangGraph checkpoints (RunStepResumeState), so a step opened by one process closes correctly after a resume on another. Closes the multi-replica gap that RedisJobStore's reconstruction branch was working around.
• feat: route code execution per agent profile (agents#416) — new optional codeSessionKey partition for transient code-session ids and file refs, plus optional baseUrl / profile assertion on CodeExecutionToolParams.

No LibreChat source changes are needed for this bump.

Change Type

• Bug fix (non-breaking change which fixes an issue)

Testing

Verification performed on the diff itself, since it is a dependency pin with no source changes:

• Confirmed 3.6.0 is published and that the subagent closure fix is present in the tag: git show v3.6.0:src/tools/subagent/SubagentExecutor.ts contains closeChildRunSteps.
• Reviewed the full public type-surface diff between v3.5.1 and v3.6.0 (src/types/stream.ts, src/types/tools.ts, src/types/graph.ts, and the export barrels). Every new field is optional and no existing signature changed, so nothing in api/ or packages/api/ needs updating.
• Compared the package's own dependencies, peerDependencies and optionalPeers at 3.6.0 against the registry and against the 3.5.1 entries — identical. That is why both lockfile diffs are confined to the @librechat/agents entry (version / resolution id / integrity) and the two workspace specs, with no transitive churn, and why the existing @librechat/agents/* hoisting overrides in bun.lock stay valid untouched.
• Regenerated package-lock.json with npm install --package-lock-only to confirm npm resolves to exactly this state, then applied the change surgically so the committed diff carries none of the unrelated libc / peer-dedup noise that a full regeneration on a different npm minor introduces.
• Cross-checked that the integrity hash in bun.lock equals the one npm independently resolved into package-lock.json.

Test Configuration:

Two things could not be executed in this environment, both for the same reason — the xlsx dependency is pinned to a direct cdn.sheetjs.com tarball URL, which the sandbox network policy denies (403 on CONNECT cdn.sheetjs.com:443):

• npm ci cannot complete, so the api / packages/api workspaces were not installed and their test suites were not run locally. CI runs them.
• bun install --lockfile-only cannot complete either — bun stores no integrity for URL dependencies and re-fetches that host on every resolve. The bun.lock entry was therefore updated directly rather than regenerated by bun. This is exact rather than approximate because the package's dependency graph is unchanged between the two versions (see above), so only three values can move and only those three did. Flagging it explicitly so the lockfile is read as hand-verified, not tool-generated; a bun install --lockfile-only on a machine that can reach that host should produce no further change.

CI runs on Node 24.16.0, which satisfies the >=24.0.0 engine 3.6.0 declares — the repo's .nvmrc and every workflow already pin that version, so the engine bump in the new release is already met.

Checklist

• My code adheres to this project's style guidelines
• I have performed a self-review of my own code
• My changes do not introduce new warnings
• Any changes dependent on mine have been merged and published in downstream modules.

[danny-avila]

@codex review

---

Generated by Claude Code

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 5b7c41a33b

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Regenerate the Bun lockfile for the agents bump

Update bun.lock alongside this manifest change. It still records both workspace requirements and the resolved package as @librechat/agents@3.5.1, which no longer satisfies ^3.6.0; therefore Bun-based checkouts lose reproducibility, and bun install --frozen-lockfile cannot accept the committed state. Bun 1.2.14's bun install --help defines that flag as “Disallow changes to lockfile,” so the lockfile needs to contain the new workspace ranges and 3.6.0 resolution rather than relying on each user to rewrite it.

Useful? React with 👍 / 👎.

[danny-avila]

Correct, and I missed it — thanks. bun.lock was only added to the repo in db67520 (the merge of #14873), so it was not on my radar when I scoped this bump. It did still record ^3.5.1 in both workspace requirement blocks and @librechat/agents@3.5.1 as the resolution, so bun install --frozen-lockfile would have rejected the committed state. Fixed in 8535fed.

One caveat worth stating plainly, since it affects how you should read that commit: I could not regenerate it with bun. bun install --lockfile-only fails here because bun stores no integrity for the xlsx URL dependency and re-fetches cdn.sheetjs.com on every resolve, which this sandbox's network policy denies:

error: GET https://cdn.sheetjs.com/xlsx-0.20.3/xlsx-0.20.3.tgz - 403
error: xlsx@https://cdn.sheetjs.com/xlsx-0.20.3/xlsx-0.20.3.tgz failed to resolve

(Confirmed at the proxy layer, not just as a bun error — the gateway answers 403 to CONNECT cdn.sheetjs.com:443.) The same constraint is why npm ci cannot run here either.

So I updated the entry directly. That is exact rather than approximate in this specific case, because the package's dependency graph does not move between the two versions — I verified against the registry that dependencies, peerDependencies and optionalPeers at 3.6.0 are byte-identical to 3.5.1. Only three things can therefore change, and only those three did:

• the two workspace requirement blocks → ^3.6.0
• the resolution id → @librechat/agents@3.6.0
• the integrity → sha512-PWDd29NL2Mtuomt… — which I cross-checked equals the hash npm independently resolved into package-lock.json

The existing @librechat/agents/* hoisting overrides (@anthropic-ai/sdk, @opentelemetry/sdk-node, diff, openai, uuid) stay valid untouched, since the dependency set they resolve is unchanged. Net diff is 3 lines. I also confirmed the file still parses.

If you'd rather have a bun-authored lockfile than a hand-verified one, a bun install --lockfile-only on a machine that can reach cdn.sheetjs.com should produce no further change — but I'd rather flag that I couldn't run it than imply I did.

---

Generated by Claude Code

[danny-avila]

@codex review

Round 1's single finding (stale bun.lock) is addressed in 8535fed — details and the one caveat (bun could not be run here) are in the thread reply.

---

Generated by Claude Code

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Keep them coming!

Reviewed commit: 8535fede3a

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".