Merge release-1.11.2 into main

Author: erichare

.secrets.baseline

@@ -123,6 +123,7 @@ RUN useradd user -u 1000 -g 0 --no-create-home --home-dir /app/data
 
 COPY --from=builder --chown=1000 /app/.venv /app/.venv
 ENV PATH="/app/.venv/bin:$PATH"
+ENV HOME=/app/data
 ENV BASH_ENV="" \
     ENV="" \
     PROMPT_COMMAND=""
@@ -134,15 +135,15 @@ ENV BASH_ENV="" \
 # write secret_key, profile_pictures, etc. Without this, the volume is created
 # as root:root and Langflow crashes during startup with PermissionError on
 # /app/langflow/secret_key. See https://github.com/langflow-ai/langflow/issues/10437
-RUN mkdir -p /app/langflow && chown -R 1000:0 /app/langflow && chmod -R g+rwX /app/langflow
+RUN mkdir -p /app/data /app/langflow \
+    && chown -R 1000:0 /app/data /app/langflow \
+    && chmod -R g+rwX /app/data /app/langflow
 
 # Give the runtime user (uid 1000) a writable npm cache. The image ships Node so
-# users can spawn stdio MCP servers via `npx`, but on the ubi10 base
-# HOME=/opt/app-root/src is not owned by uid 1000, so npx otherwise fails with
-# `EACCES` on ~/.npm/_cacache and every stdio MCP server registers but never
-# lists any tools (toolsCount stays null). Pin npm's cache to a
-# uid-1000-owned dir (immune to the base image's HOME) and hand ownership of the
-# default HOME cache to the runtime user as a fallback.
+# users can spawn stdio MCP servers via `npx`. Pin npm's cache to a
+# uid-1000-owned dir so callers that override HOME cannot make the cache
+# read-only, and keep the UBI base image's default HOME cache writable as a
+# fallback.
 # See https://github.com/langflow-ai/langflow/pull/13893 (ubi10 base change).
 ENV NPM_CONFIG_CACHE=/app/.npm
 RUN mkdir -p /app/.npm /opt/app-root/src/.npm \

docker/build_and_push.Dockerfile

@@ -89,6 +89,7 @@ RUN useradd --uid 1000 --gid 0 --no-create-home --home-dir /app/data user
 # Copy only the virtual environment
 COPY --from=builder --chown=1000:0 /app/.venv /app/.venv
 ENV PATH="/app/.venv/bin:$PATH"
+ENV HOME=/app/data
 ENV BASH_ENV="" \
     ENV="" \
     PROMPT_COMMAND=""
@@ -104,7 +105,7 @@ ENV BASH_ENV="" \
 # Note: .venv is already owned by 1000:0 via COPY --chown above, so no recursive chown needed
 RUN mkdir -p /app/data /app/langflow \
     && chown -R 1000:0 /app/data /app/langflow \
-    && chmod -R g+rwX /app/langflow \
+    && chmod -R g+rwX /app/data /app/langflow \
     && chown 1000:0 /app
 
 LABEL org.opencontainers.image.title=langflow-backend

docker/build_and_push_backend.Dockerfile

@@ -126,6 +126,7 @@ RUN useradd user -u 1000 -g 0 --no-create-home --home-dir /app/data
 
 COPY --from=builder --chown=1000 /app/.venv /app/.venv
 ENV PATH="/app/.venv/bin:$PATH"
+ENV HOME=/app/data
 ENV BASH_ENV="" \
     ENV="" \
     PROMPT_COMMAND=""
@@ -137,14 +138,15 @@ ENV BASH_ENV="" \
 # write secret_key, profile_pictures, etc. Without this, the volume is created
 # as root:root and Langflow crashes during startup with PermissionError on
 # /app/langflow/secret_key. See https://github.com/langflow-ai/langflow/issues/10437
-RUN mkdir -p /app/langflow && chown -R 1000:0 /app/langflow && chmod -R g+rwX /app/langflow
+RUN mkdir -p /app/data /app/langflow \
+    && chown -R 1000:0 /app/data /app/langflow \
+    && chmod -R g+rwX /app/data /app/langflow
 
 # Give the runtime user (uid 1000) a writable npm cache. The image ships Node so
-# users can spawn stdio MCP servers via `npx`, but on the ubi10 base
-# HOME=/opt/app-root/src is not owned by uid 1000, so npx otherwise fails with
-# `EACCES` on ~/.npm/_cacache and stdio MCP servers never list any tools. Pin
-# npm's cache to a uid-1000-owned dir (immune to the base image's HOME) and hand
-# ownership of the default HOME cache to the runtime user as a fallback.
+# users can spawn stdio MCP servers via `npx`. Pin npm's cache to a
+# uid-1000-owned dir so callers that override HOME cannot make the cache
+# read-only, and keep the UBI base image's default HOME cache writable as a
+# fallback.
 # See https://github.com/langflow-ai/langflow/pull/13893 (ubi10 base change).
 ENV NPM_CONFIG_CACHE=/app/.npm
 RUN mkdir -p /app/.npm /opt/app-root/src/.npm \

docker/build_and_push_base.Dockerfile

@@ -114,6 +114,7 @@ RUN useradd user -u 1000 -g 0 --no-create-home --home-dir /app/data
 
 COPY --from=builder --chown=1000 /app/.venv /app/.venv
 ENV PATH="/app/.venv/bin:$PATH"
+ENV HOME=/app/data
 ENV BASH_ENV="" \
     ENV="" \
     PROMPT_COMMAND=""
@@ -125,7 +126,9 @@ ENV BASH_ENV="" \
 # write secret_key, profile_pictures, etc. Without this, the volume is created
 # as root:root and Langflow crashes during startup with PermissionError on
 # /app/langflow/secret_key. See https://github.com/langflow-ai/langflow/issues/10437
-RUN mkdir -p /app/langflow && chown -R 1000:0 /app/langflow && chmod -R g+rwX /app/langflow
+RUN mkdir -p /app/data /app/langflow \
+    && chown -R 1000:0 /app/data /app/langflow \
+    && chmod -R g+rwX /app/data /app/langflow
 
 LABEL org.opencontainers.image.title=langflow
 LABEL org.opencontainers.image.authors=['Langflow']

docker/build_and_push_ep.Dockerfile

@@ -114,6 +114,7 @@ RUN useradd user -u 1000 -g 0 --no-create-home --home-dir /app/data
 
 COPY --from=builder --chown=1000 /app/.venv /app/.venv
 ENV PATH="/app/.venv/bin:$PATH"
+ENV HOME=/app/data
 ENV BASH_ENV="" \
     ENV="" \
     PROMPT_COMMAND=""
@@ -125,14 +126,15 @@ ENV BASH_ENV="" \
 # write secret_key, profile_pictures, etc. Without this, the volume is created
 # as root:root and Langflow crashes during startup with PermissionError on
 # /app/langflow/secret_key. See https://github.com/langflow-ai/langflow/issues/10437
-RUN mkdir -p /app/langflow && chown -R 1000:0 /app/langflow && chmod -R g+rwX /app/langflow
+RUN mkdir -p /app/data /app/langflow \
+    && chown -R 1000:0 /app/data /app/langflow \
+    && chmod -R g+rwX /app/data /app/langflow
 
 # Give the runtime user (uid 1000) a writable npm cache. The image ships Node so
-# users can spawn stdio MCP servers via `npx`, but on the ubi10 base
-# HOME=/opt/app-root/src is not owned by uid 1000, so npx otherwise fails with
-# `EACCES` on ~/.npm/_cacache and stdio MCP servers never list any tools. Pin
-# npm's cache to a uid-1000-owned dir (immune to the base image's HOME) and hand
-# ownership of the default HOME cache to the runtime user as a fallback.
+# users can spawn stdio MCP servers via `npx`. Pin npm's cache to a
+# uid-1000-owned dir so callers that override HOME cannot make the cache
+# read-only, and keep the UBI base image's default HOME cache writable as a
+# fallback.
 # See https://github.com/langflow-ai/langflow/pull/13893 (ubi10 base change).
 ENV NPM_CONFIG_CACHE=/app/.npm
 RUN mkdir -p /app/.npm /opt/app-root/src/.npm \

docker/build_and_push_with_extras.Dockerfile

@@ -5,15 +5,15 @@ slug: /policies
 
 The **Policies** component leverages [ToolGuard](https://github.com/AgentToolkit/toolguard) to automatically generate guard code that validates tool execution against defined business policies.
 
-With this component, developers define business policies in natural language and integrate policy enforcement into agent workflows. It automatically generates validation code for tools from those policies, protects tool execution by enforcing policy compliance at runtime, and caches generated guard code for better performance.
+With this component, developers define business policies in natural language and integrate policy enforcement into agent workflows. It automatically generates validation code for tools from those policies, protects tool execution by enforcing policy compliance at runtime, and stores generated guard code in the flow for reuse.
 
 The component supports **Generate** activity, which runs ToolGuard’s buildtime flow to produce new guard code from policies, and **Guard** activity, which reuses previously generated guard code for faster runs.
 
 ## Use the component in a flow
 
 When `enabled` is `true`, you must supply at least one policy before generating guards.
 Generated guard code is written under `tmp_toolguard/{project_name}/`, with **Step 1** producing guard specifications from policies in `Step_1/`, and **Step 2** turning those specifications into executable guard code in `Step_2/`.
-If you switch to **Guard** (apply cached guards), the project directory must already contain valid generated guard code. The component handles module caching and cleanup automatically.
+The generated code is also stored in the Policies node. After switching to **Guard**, the component loads that stored code, so the local `tmp_toolguard` directory is not required. If the node does not contain complete generated code, run **Generate** again.
 
 For more information, see the [ToolGuard GitHub repository](https://github.com/AgentToolkit/toolguard).
 
@@ -22,11 +22,10 @@ For more information, see the [ToolGuard GitHub repository](https://github.com/A
 | Name | Type | Description |
 |------|------|-------------|
 | enabled | Boolean | Input parameter. If `true`, ToolGuard runs before tool execution; if `false`, policy validation is skipped. |
-| mode | String | Input parameter. **Activity**: **Generate** runs buildtime to create guard code, or **Guard** loads existing guards from the project folder. |
+| mode | String | Input parameter. **Activity**: **Generate** runs buildtime to create guard code, or **Guard** loads generated guards stored in the flow. |
 | project | String | Input parameter. Folder name for generated code under `tmp_toolguard/` (default `my_project`). |
 | in_tools | List[Tool] | Input parameter. Tools the agent can use; they are wrapped with policy guards when enabled. |
 | policies | List[String] | Input parameter. One or more clear, self-contained business policy strings. Required when generating guards. |
 | model | Model | Input parameter. LLM used for Policies buildtime; Anthropic Claude Sonnet is recommended. Required when generating guards. |
 | api_key | String | Input parameter. Model provider API key (advanced). Required when generating guards. |
 | guarded_tools | List[Tool] | Output parameter. Tools with policy enforcement applied. Returns the original tools when the component is disabled. |
-

docs/docs/Components/policies.mdx

@@ -12,7 +12,7 @@ To block custom component creation on a Langflow server, set the following [envi
 LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false
 ```
 
-When set to `false`, Langflow blocks creating custom components and changing code in the visual editor.
+When set to `false`, Langflow blocks creating custom components, changing code in the visual editor, and running [registered built-in code-execution components](/api-keys-and-authentication#multi-tenant-component-hardening).
 
 When unset or `true`, Langflow allows custom code.
 Existing installations keep the default `true` behavior until you opt in to this restriction.
@@ -62,4 +62,4 @@ Default is `true`, which preserves existing behavior. The setting has no effect
 For more information, see:
 
 * [Environment variables](/environment-variables#visual-editor-and-playground-behavior)
-* [Security](/security)
+* [Security](/security)

docs/docs/Deployment/deployment-block-custom-components.mdx

@@ -507,12 +507,12 @@ For more information, see [Docker image defaults](/deployment-docker#docker-imag
 
 Enable these flags when untrusted users can build flows on this server.
 
-The `LANGFLOW_ALLOW_CUSTOM_COMPONENTS` and `LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS` flags are _complementary_.
-`LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false` blocks user-authored component code, but built-in code-execution components still pass that check because their class code is trusted. Set `LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true` to block those built-in components as well.
+The `LANGFLOW_ALLOW_CUSTOM_COMPONENTS` and `LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS` flags support two deployment modes.
+`LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false` blocks user-authored component code and registered built-in code-execution components at runtime. Set `LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true` independently when custom components should remain enabled but built-in code execution should be disabled.
 
 To enable these flags, set the following:
 
-* `LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false`: blocks user-authored component code. See [Block custom components](/deployment-block-custom-components).
+* `LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false`: blocks user-authored component code and registered built-in code-execution components. See [Block custom components](/deployment-block-custom-components).
 * `LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS=true`: blocks built-in code-execution components.
 * `LANGFLOW_RESTRICT_LOCAL_FILE_ACCESS=true`: confines built-in file access to the upload sandbox.
 * `LANGFLOW_MCP_SERVER_DOCKER_HARDENING=true`: tightens Docker MCP server arguments.

docs/docs/Develop/api-keys-and-authentication.mdx

@@ -446,7 +446,7 @@ See [Telemetry](/contributing-telemetry).
 | `LANGFLOW_BUNDLE_URLS` | List[String] | `[]` | A list of URLs from which to load custom bundles. Supports GitHub URLs. If `LANGFLOW_AUTO_LOGIN=True`, flows from these bundles are loaded into the database. |
 | `LANGFLOW_COMPONENTS_PATH` | String | Not set | Path to a directory containing custom components. Typically used if you have local custom components or you are building a Docker image with custom components. |
 | `LANGFLOW_COMPONENTS_INDEX_PATH` | String | Not set | File path or URL (`http://` or `https://`) to a prebuilt component index JSON file used to populate built-in components in the visual editor. When not set, Langflow uses the included index. Useful for supplying a curated component index, for example in airgapped deployments. For more information, see [Block custom components](/deployment-block-custom-components). |
-| `LANGFLOW_ALLOW_CUSTOM_COMPONENTS` | Boolean | `True` | If `false`, disables custom components and in-editor editing of component code. This feature is in beta. For more information, see [Block custom components](/deployment-block-custom-components) and [Component hardening for untrusted users](/api-keys-and-authentication#multi-tenant-component-hardening). |
+| `LANGFLOW_ALLOW_CUSTOM_COMPONENTS` | Boolean | `True` | If `false`, disables custom components, in-editor editing of component code, and registered built-in code-execution components at runtime. This feature is in beta. For more information, see [Block custom components](/deployment-block-custom-components) and [Component hardening for untrusted users](/api-keys-and-authentication#multi-tenant-component-hardening). |
 | `LANGFLOW_ALLOW_COMPONENTS_PATHS_OVERRIDE` | Boolean | `True` | When `false` alongside `LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false`, components contributed by `LANGFLOW_COMPONENTS_PATH` and `LANGFLOW_COMPONENTS_INDEX_PATH` no longer bypass the block. Has no effect when `LANGFLOW_ALLOW_CUSTOM_COMPONENTS=true`. For more information, see [Block custom components](/deployment-block-custom-components). |
 | `LANGFLOW_BLOCK_CODE_INTERPRETER_COMPONENTS` | Boolean | `False` | If `true`, blocks built-in code-execution components (Python Interpreter, REPL/Code tools, Smart Transform, and code-running agents). See [Component hardening for untrusted users](/api-keys-and-authentication#multi-tenant-component-hardening). |
 | `LANGFLOW_RESTRICT_LOCAL_FILE_ACCESS` | Boolean | `False` | If `true`, confines built-in file components to the upload storage directory and blocks local-file SQL dialects and local Git clones. See [Component hardening for untrusted users](/api-keys-and-authentication#multi-tenant-component-hardening). |