✨ feat: stateful_code_sessions capability for warm Code API sandbox sessions (experimental) - #14150
Conversation
There was a problem hiding this comment.
Pull request overview
Adds an off-by-default stateful_code_sessions capability to let code-execution tools (bash/execute_code) reuse a warm per-conversation Code API sandbox session when enabled via agents endpoint capabilities, while preserving stateless behavior by default.
Changes:
- Introduces
AgentCapabilities.stateful_code_sessions(not included in defaults). - Adds
resolveStatefulCodeSessionsgating and conditionally injectstoolExecution.sandbox.statefulSessions: trueinto the agents run config. - Threads a
statefulSessionsflag into bash/execute_code tool factories to adjust tool descriptions when the capability is enabled.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| packages/data-provider/src/config.ts | Adds new agent capability enum value for stateful code sessions. |
| packages/api/src/agents/statefulCodeSessions.spec.ts | Adds unit tests covering stateful session gating behavior. |
| packages/api/src/agents/run.ts | Implements capability gate and conditionally enables sandbox stateful sessions in run config. |
| api/server/services/ToolService.js | Passes statefulSessions into bash tool creation when capability and code execution are enabled. |
| api/app/clients/tools/util/handleTools.js | Passes statefulSessions into execute_code tool creation based on capability check. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| if (!codeEnvActive) { | ||
| return false; | ||
| } | ||
| return new Set(agentsEndpointConfig?.capabilities).has(AgentCapabilities.stateful_code_sessions); |
danny-avila
changed the title
3cd770b to
e75185c
Compare
…essions Wire the @librechat/agents stateful sandbox sub-config behind a new, off-by-default stateful_code_sessions agent capability. createRun sets toolExecution.sandbox.statefulSessions when code execution is active in the run AND the capability is enabled; execute_code and bash_tool factories get the param so their descriptions hedge toward persistence. Rides the existing variable-not-literal runConfig pattern, so it no-ops until @librechat/agents is bumped to the version shipping the sandbox sub-config.
Stateful sessions now require the agent's own opt-in, not just the admin capability. New agent field stateful_code_sessions (schema + validation + types) surfaces as a toggle in Agent Builder Advanced settings, gated on the app capability and disabled without Code Interpreter. initializeAgent resolves the per-agent truth (admin capability AND builder opt-in AND code env) once: the registered bash_tool description, the execute_code factory, and createRun's toolExecution.sandbox gate all read the same resolved value. statefulSessionsAvailable threads through the same call sites as codeEnvAvailable, including handoff discovery and added convos.
…iven tool path The event-driven ON_TOOL_EXECUTE handler built config.toolCall without the resolved runtime_session_hint, so BashExecutor/CodeExecutor never sent runtime_session_hint to the Code API. Every conversation then collapsed onto the server-derived default session (no per-conversation isolation). Copy tc.runtimeSessionHint onto toolCallConfig._runtime_session_hint, mirroring the SDK direct-execution path.
de52d26 to
45c1cd7
Compare
|
@codex review |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 45c1cd74c6
ℹ️ 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".
| * `toolExecution.sandbox` gate all agree for this agent. */ | ||
| const effectiveStatefulSessions = | ||
| effectiveCodeEnvAvailable && | ||
| params.statefulSessionsAvailable === true && |
There was a problem hiding this comment.
When using the exported OpenAI-compatible service (packages/api/src/agents/openai/service.ts), it still derives and passes only codeEnvAvailable to deps.initializeAgent. Since this new gate requires params.statefulSessionsAvailable === true, an agent with execute_code, the app-level stateful_code_sessions capability, and agent.stateful_code_sessions: true is initialized with statefulCodeSessions false on that route, so createRun never sends toolExecution.sandbox and the feature silently does nothing. Please derive and pass the new capability alongside codeEnvAvailable.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in c0919bc. packages/api/src/agents/openai/service.ts now derives statefulSessionsAvailable from the agents endpoint capabilities and passes it to deps.initializeAgent alongside codeEnvAvailable, so this OpenAI-compatible route resolves stateful sessions identically to the in-repo controllers.
| ...(statefulCodeSessions && { | ||
| toolExecution: { sandbox: { statefulSessions: true } }, | ||
| }), |
There was a problem hiding this comment.
In a multi-agent run where one code-capable agent opts into stateful sessions and another code-capable agent does not, this run-level toolExecution switch enables stateful sandbox handling for the whole graph. That means non-opted-in agents in the same run can still have their bash_tool / execute_code calls persisted under the conversation session, even though only the opted-in agent's tool definition was hedged as stateful. Please make the SDK/config gate per-agent or avoid mixing opted-out code agents into a globally stateful run.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Valid observation — this is an intentional run-level gate for v1. The SDK's toolExecution.sandbox.statefulSessions is a run-config (not per-agent), and the runtime session id is derived per-conversation (hash(tenant, user, thread_id)), so any code-capable agent in the conversation shares the conversation's warm workspace by design; anyAgentHasStatefulSessions enables it when at least one reachable agent opts in.
The residual gap you flag — a non-opted-in code agent's bash_tool/execute_code description isn't hedged as stateful even though its calls persist under the conversation session — is real, but closing it cleanly needs per-agent toolExecution support in @librechat/agents (the run-config can't vary per agent today). Tracking that as a follow-up; keeping the run-level, conversation-scoped behavior here.
| if (tc.runtimeSessionHint != null && tc.runtimeSessionHint !== '') { | ||
| toolCallConfig._runtime_session_hint = tc.runtimeSessionHint; |
There was a problem hiding this comment.
When read_file, create_file, or edit_file is the first sandbox operation in a stateful conversation, those host-handled branches return before this generic tool path, and readSandboxFile / writeSandboxFile only receive session_id and files. With no existing session_id yet, their /exec calls still lack the per-conversation runtime hint and fall back to the Code API's default session, so host file reads/writes can leak across conversations or miss the intended stateful workspace. Please thread tc.runtimeSessionHint through the host sandbox helpers as well.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in c0919bc. Threaded the per-conversation runtime_session_hint (tc.runtimeSessionHint) through the host file-authoring path: added it to the readSandboxFile/writeSandboxFile option types (handlers.ts), forwarded it at all three call sites (handleReadFileCall plus the read/write helpers used by create_file/edit_file), and the implementations in api/server/services/Files/Code/process.js now include it in the /exec body. So a host file op that is the first sandbox call in a conversation joins the same runtime session instead of falling back to the Code API's default.
| checked={enabled && codeEnabled === true} | ||
| onCheckedChange={handleChange} |
There was a problem hiding this comment.
If an agent has stateful sessions enabled and the user later turns off Code Interpreter, this switch renders unchecked and disabled but the form value remains true; composeAgentUpdatePayload still persists stateful_code_sessions: true. The saved agent therefore doesn't match the UI, and re-enabling Code Interpreter later silently reactivates stateful sessions. Please clear the form value when codeEnabled becomes false, or omit/force false in the payload when the code tool is disabled.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in c0919bc. StatefulSessions.tsx now clears the form value via a useEffect — when execute_code is turned off it sets stateful_code_sessions to false (dirty), so the saved agent matches the disabled UI and re-enabling Code Interpreter later doesn't silently reactivate stateful sessions.
- OpenAI-compatible service (packages/api/src/agents/openai/service.ts) now derives and passes statefulSessionsAvailable alongside codeEnvAvailable, so the feature activates on that route (previously statefulCodeSessions resolved false there and createRun never sent toolExecution.sandbox). - Thread runtime_session_hint through the host file-authoring tools (create_file/edit_file/read_file): those host branches return before the generic tool path, so readSandboxFile/writeSandboxFile now forward the per-conversation hint instead of falling back to the Code API default session. - StatefulSessions builder toggle clears its form value when Code Interpreter is disabled, so a saved agent matches the disabled UI and re-enabling code doesn't silently reactivate stateful sessions.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c0919bc726
ℹ️ 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".
| useEffect(() => { | ||
| if (codeEnabled !== true && enabled) { | ||
| setValue(AgentCapabilities.stateful_code_sessions, false, { shouldDirty: true }); | ||
| } |
There was a problem hiding this comment.
When a user disables Code Interpreter from the main builder and saves without opening Advanced settings, this effect never runs because StatefulSessions is only mounted in the Advanced panel. composeAgentUpdatePayload will therefore keep sending the existing stateful_code_sessions: true, so re-enabling code later silently turns warm sessions back on despite the prerequisite having been disabled; this normalization needs to live in always-mounted form or payload logic.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 14a34f2. You're right — the round-1 useEffect only fired while the Advanced panel was mounted, so disabling Code Interpreter from the main builder (without opening Advanced) never cleared the opt-in.
Moved the normalization into composeAgentUpdatePayload, the always-run save path:
const normalizedStatefulCodeSessions =
data.execute_code === true ? stateful_code_sessions : false;stateful_code_sessions is now forced to false on save whenever execute_code !== true, regardless of whether Advanced was ever opened, so a stale opt-in can't silently reactivate warm sessions when code is re-enabled later. Reverted the mount-scoped useEffect and added spec coverage for both branches.
| ...(statefulCodeSessions && { | ||
| toolExecution: { sandbox: { statefulSessions: true } }, |
There was a problem hiding this comment.
In a mixed multi-agent run where any one reachable agent opted into stateful sessions, this run-wide toolExecution.sandbox setting is applied to the entire graph. The execution path forwards the resulting runtime session hint for sandbox tool calls, so other code-enabled agents in the same run that left stateful_code_sessions off can still run against the conversation-persistent workspace, violating the per-agent opt-in and changing their /mnt/data lifetime unexpectedly.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Same intentional run-level scope as the round-1 thread on this file. The SDK's toolExecution.sandbox.statefulSessions is a run-config, not per-agent, and the runtime session id is hash(tenant, user, thread_id) — conversation-scoped — so once any reachable agent opts in, the conversation's warm workspace is shared by design. The forwarded _runtime_session_hint you flag is that mechanism, not a separate leak: it routes calls to the same conversation session.
The residual gap — a non-opted-in code agent's /mnt/data lifetime changing because it now runs against the persistent workspace — is real, but it can only be closed cleanly with per-agent toolExecution support in @librechat/agents (the run-config can't vary per agent today). Keeping the run-level, conversation-scoped behavior for v1 and tracking per-agent scoping as an SDK follow-up.
… disabled Addresses Codex review (round 2): a stale `stateful_code_sessions` opt-in could persist when Code Interpreter (`execute_code`) is disabled from the main agent builder without opening Advanced settings, silently reactivating warm sessions if code was later re-enabled. - AgentPanel: normalize in `composeAgentUpdatePayload` (the always-run save path) so `stateful_code_sessions` is forced to `false` whenever `execute_code !== true`, regardless of whether Advanced was opened. - StatefulSessions: revert the mount-scoped useEffect (round-1 approach) — it only fired while the Advanced panel was mounted, missing this path. - Add spec coverage for both branches of the normalization.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 14a34f2152
ℹ️ 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".
| // thread_id. Requires @librechat/agents with `toolExecution.sandbox`; | ||
| // older versions ignore the field. | ||
| ...(statefulCodeSessions && { | ||
| toolExecution: { sandbox: { statefulSessions: true } }, |
There was a problem hiding this comment.
When a run mixes code-enabled agents and only one has statefulCodeSessions true (for example, a stateless primary delegating to an opted-in subagent), this single run-level toolExecution.sandbox.statefulSessions setting applies to the whole graph. That means sandbox calls from agents whose builder toggle is off can still receive the persistent per-conversation session behavior, so their code may reuse files/packages/state from prior calls despite being configured as stateless. Please scope the session hint per agent/tool, or avoid enabling the run-level setting for mixed graphs.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Third pass on this one — and note that Finding A (the stale-opt-in normalization) was not re-raised, so that fix on 14a34f215 is confirmed. Thanks.
On scoping: this is a deliberate v1 tradeoff, and both workarounds you suggest have a failure mode — which is exactly why I'm holding at run-level until the SDK supports per-agent toolExecution:
- "Scope the session hint per agent/tool" — not possible from LibreChat today.
statefulSessionsis a single run-level flag in@librechat/agents, and the executor stamps_runtime_session_hintfrom the run config; LibreChat can't vary it per agent without SDK support. Tracked as an SDK follow-up. - "Don't enable for mixed graphs" (i.e. require all code-capable agents to opt in) — trades the reported surprise for the opposite one: an agent whose builder toggle is explicitly on would silently get no persistence in a mixed graph. Silently dropping an explicit opt-in is arguably worse than the current "any reachable opt-in shares the conversation workspace," especially since the session is conversation-scoped (
hash(tenant, user, thread_id)) by design.
Keeping the run-level, conversation-scoped behavior for v1 with this documented; the clean per-agent fix lands with SDK support.
…essions (experimental) (danny-avila#14150) * ✨ feat: stateful_code_sessions capability for warm Code API sandbox sessions Wire the @librechat/agents stateful sandbox sub-config behind a new, off-by-default stateful_code_sessions agent capability. createRun sets toolExecution.sandbox.statefulSessions when code execution is active in the run AND the capability is enabled; execute_code and bash_tool factories get the param so their descriptions hedge toward persistence. Rides the existing variable-not-literal runConfig pattern, so it no-ops until @librechat/agents is bumped to the version shipping the sandbox sub-config. * ✨ feat: per-agent stateful code sessions (builder toggle + init gating) Stateful sessions now require the agent's own opt-in, not just the admin capability. New agent field stateful_code_sessions (schema + validation + types) surfaces as a toggle in Agent Builder Advanced settings, gated on the app capability and disabled without Code Interpreter. initializeAgent resolves the per-agent truth (admin capability AND builder opt-in AND code env) once: the registered bash_tool description, the execute_code factory, and createRun's toolExecution.sandbox gate all read the same resolved value. statefulSessionsAvailable threads through the same call sites as codeEnvAvailable, including handoff discovery and added convos. * 🐛 fix: propagate runtime_session_hint to sandbox executor in event-driven tool path The event-driven ON_TOOL_EXECUTE handler built config.toolCall without the resolved runtime_session_hint, so BashExecutor/CodeExecutor never sent runtime_session_hint to the Code API. Every conversation then collapsed onto the server-derived default session (no per-conversation isolation). Copy tc.runtimeSessionHint onto toolCallConfig._runtime_session_hint, mirroring the SDK direct-execution path. * 🐛 fix: address Codex review findings for stateful code sessions - OpenAI-compatible service (packages/api/src/agents/openai/service.ts) now derives and passes statefulSessionsAvailable alongside codeEnvAvailable, so the feature activates on that route (previously statefulCodeSessions resolved false there and createRun never sent toolExecution.sandbox). - Thread runtime_session_hint through the host file-authoring tools (create_file/edit_file/read_file): those host branches return before the generic tool path, so readSandboxFile/writeSandboxFile now forward the per-conversation hint instead of falling back to the Code API default session. - StatefulSessions builder toggle clears its form value when Code Interpreter is disabled, so a saved agent matches the disabled UI and re-enabling code doesn't silently reactivate stateful sessions. * 🐛 fix: normalize stateful_code_sessions on save when Code Interpreter disabled Addresses Codex review (round 2): a stale `stateful_code_sessions` opt-in could persist when Code Interpreter (`execute_code`) is disabled from the main agent builder without opening Advanced settings, silently reactivating warm sessions if code was later re-enabled. - AgentPanel: normalize in `composeAgentUpdatePayload` (the always-run save path) so `stateful_code_sessions` is forced to `false` whenever `execute_code !== true`, regardless of whether Advanced was opened. - StatefulSessions: revert the mount-scoped useEffect (round-1 approach) — it only fired while the Advanced panel was mounted, missing this path. - Add spec coverage for both branches of the normalization.
…essions (experimental) (danny-avila#14150) * ✨ feat: stateful_code_sessions capability for warm Code API sandbox sessions Wire the @librechat/agents stateful sandbox sub-config behind a new, off-by-default stateful_code_sessions agent capability. createRun sets toolExecution.sandbox.statefulSessions when code execution is active in the run AND the capability is enabled; execute_code and bash_tool factories get the param so their descriptions hedge toward persistence. Rides the existing variable-not-literal runConfig pattern, so it no-ops until @librechat/agents is bumped to the version shipping the sandbox sub-config. * ✨ feat: per-agent stateful code sessions (builder toggle + init gating) Stateful sessions now require the agent's own opt-in, not just the admin capability. New agent field stateful_code_sessions (schema + validation + types) surfaces as a toggle in Agent Builder Advanced settings, gated on the app capability and disabled without Code Interpreter. initializeAgent resolves the per-agent truth (admin capability AND builder opt-in AND code env) once: the registered bash_tool description, the execute_code factory, and createRun's toolExecution.sandbox gate all read the same resolved value. statefulSessionsAvailable threads through the same call sites as codeEnvAvailable, including handoff discovery and added convos. * 🐛 fix: propagate runtime_session_hint to sandbox executor in event-driven tool path The event-driven ON_TOOL_EXECUTE handler built config.toolCall without the resolved runtime_session_hint, so BashExecutor/CodeExecutor never sent runtime_session_hint to the Code API. Every conversation then collapsed onto the server-derived default session (no per-conversation isolation). Copy tc.runtimeSessionHint onto toolCallConfig._runtime_session_hint, mirroring the SDK direct-execution path. * 🐛 fix: address Codex review findings for stateful code sessions - OpenAI-compatible service (packages/api/src/agents/openai/service.ts) now derives and passes statefulSessionsAvailable alongside codeEnvAvailable, so the feature activates on that route (previously statefulCodeSessions resolved false there and createRun never sent toolExecution.sandbox). - Thread runtime_session_hint through the host file-authoring tools (create_file/edit_file/read_file): those host branches return before the generic tool path, so readSandboxFile/writeSandboxFile now forward the per-conversation hint instead of falling back to the Code API default session. - StatefulSessions builder toggle clears its form value when Code Interpreter is disabled, so a saved agent matches the disabled UI and re-enabling code doesn't silently reactivate stateful sessions. * 🐛 fix: normalize stateful_code_sessions on save when Code Interpreter disabled Addresses Codex review (round 2): a stale `stateful_code_sessions` opt-in could persist when Code Interpreter (`execute_code`) is disabled from the main agent builder without opening Advanced settings, silently reactivating warm sessions if code was later re-enabled. - AgentPanel: normalize in `composeAgentUpdatePayload` (the always-run save path) so `stateful_code_sessions` is forced to `false` whenever `execute_code !== true`, regardless of whether Advanced was opened. - StatefulSessions: revert the mount-scoped useEffect (round-1 approach) — it only fired while the Advanced panel was mounted, missing this path. - Add spec coverage for both branches of the normalization.
What
Wires the
@librechat/agentsstateful sandbox sub-config into LibreChat behind a dual opt-in: a new, off-by-defaultstateful_code_sessionsapp capability AND a per-agent toggle in the Agent Builder. When both are on, a conversation'sexecute_code/bashtools run against a warm per-session Code API workspace instead of a fresh sandbox per call.Changes
Capability and schema:
AgentCapabilities.stateful_code_sessions(off by default; not indefaultAgentCapabilities).stateful_code_sessions(Mongoose schema,IAgent, zod create/update validation,Agenttype + create/update params). Field name matches the capability value, following theend_after_toolsconvention.Agent Builder (frontend <-> backend plumbing):
Advanced/StatefulSessions.tsx), shown only when the app capability is enabled and disabled unless the agent has Code Interpreter on. Persists throughcomposeAgentUpdatePayload-> update/create endpoints -> agent document, and loads back via the standard form seeding.Backend agent initialization (per-agent gating):
initializeAgentresolves the per-agent truth once:statefulCodeSessions = admin capability AND agent.stateful_code_sessions AND effectiveCodeEnvAvailable. The resolved value drives all three surfaces so they cannot disagree:bash_tooldescription registered for the LLM (registerCodeExecutionTools, including the skill-catalog path),execute_code/bash_toolfactory params (statefulSessions),createRun, which walks per-agent flags (anyAgentHasStatefulSessions, including nested subagents) to settoolExecution: { sandbox: { statefulSessions: true } }.statefulSessionsAvailablethreads through the same call sites ascodeEnvAvailable(chat controller, OpenAI-compatible + Responses controllers, handoff discovery, added conversations), so subagents and handoffs resolve it identically.thread_id(the conversationId); the server derives the real session id ashash(tenant, user, hint), so none of this is a trust boundary.How LibreChat learns about AWS (it doesn't)
LibreChat needs zero AWS configuration for this feature. The boundary is deliberate:
CODE_BASEURL+ the existing Code API auth). Its only new wire artifact is theruntime_session_hintfield.CODEAPI_SANDBOX_BACKEND=lambda-microvmvs the defaulthttp), the MicroVM image ARN, execution roles, network connectors, the S3 checkpoint bucket, and AWS credentials via its own environment.http, the hint is ignored and behavior is exactly today's.Safety
Off by default twice over (app capability + per-agent toggle). All fields ride the variable-not-literal
runConfigpattern, so they typecheck and no-op against the currently pinned@librechat/agents; they activate once the SDK is bumped to the version shippingtoolExecution.sandbox.Tests
statefulCodeSessions.spec.ts: per-agent walk (top-level, nested subagents, cycles, defaults-off).packages/apiagents suite (41 suites, 1087 tests) green; apiinitialize.spec.js(15) and clientAgentPanel.helpers.spec.ts(9) green.packages/apitsc 0 errors, client tsc 0 errors, eslint + import-sort clean.Depends on
The
@librechat/agentsbump to the version with the sandbox sub-config (companion PR danny-avila/agents#291).Testing this end to end (from scratch, across the three PRs)
This PR is the top of a three-repo stack. Nothing here is user-visible until the other two are in place, so start by understanding the order:
danny-avila/agents#291- the SDK surface (toolExecution.sandbox+statefulSessions). The linchpin.ClickHouse/code-interpreter#16- the Code API service with the Lambda MicroVM backend and hookless per-request session binding.Activating this PR before the published agents release. LibreChat depends on
@librechat/agents, and the sandbox surface is not published yet, so the fields here safely no-op against the pinned version. To test the real behavior, build the agents branch and link it (npm link @librechat/agentsagainst a local build ofagents#291, or point the dependency at that branch), then rebuild LibreChat. Until you do, the toggle persists but is inert.Tier 0 - unit tests (no infra, minutes)
npm test(the statefulToolNode.session/CodeExecutor.stateful/BashExecutorsuites).bun run testinservice/andapi/(fake AWS client +Bun.servefakes, no AWS).cd packages/api && npx jest statefulCodeSessions run.spec.Tier 1 - wiring smoke (local Code API, no AWS)
Verifies capability -> agent toggle -> run config -> SDK -> wire, without needing a stateful backend.
#16locally (the defaulthttpbackend is fine for this tier).CODE_BASEURLto your local Code API and provide Code API credentials the same way you do forexecute_codetoday.librechat.yaml, enable the capability:runtime_session_hint(= the conversationId) on the/execrequest. (Thehttpbackend ignores the hint, so there is no persistence yet - expected.)Tier 2 - real statefulness (Code API session backend)
Switch the Code API to the session backend (see
#16for full setup):CODEAPI_SANDBOX_BACKEND=lambda-microvm,CODEAPI_RUNTIME_SESSION_MODE=affinity, and a session-workspace runner image (SANDBOX_SESSION_WORKSPACE_ENABLED=true). For the real-MicroVM path on AWS,#16documents the hookless image build +RunMicrovm+ the two-turn E2E. All AWS setup lives there - LibreChat's config does not change between tiers.The acceptance test (what "working" looks like)
With the capability on and the agent's toggle on, in one conversation:
/mnt/data/answer.txt."/mnt/data/answer.txtand tell me the number."The agent reads back
42in message 2. Flip the agent's toggle off (or the capability) and the same message 2 finds no file (fresh-per-job). That difference is the feature.