Merge branch 'release-1.12.0' into workflow-api-prod

Author: Jkavia

.secrets.baseline

@@ -201,9 +201,9 @@ RUN ln -s ../lib/node_modules/npm/bin/npm-cli.js /usr/local/bin/npm \
     && ln -s ../lib/node_modules/npm/bin/npx-cli.js /usr/local/bin/npx
 
 RUN useradd user -u 1000 -g 0 --no-create-home --home-dir /app/data \
-    && mkdir -p /app/langflow \
-    && chown -R 1000:0 /app/langflow \
-    && chmod -R g+rwX /app/langflow
+    && mkdir -p /app/data /app/langflow \
+    && chown -R 1000:0 /app/data /app/langflow \
+    && chmod -R g+rwX /app/data /app/langflow
 
 # Give uid 1000 a writable npm cache. The image ships Node so users can spawn
 # stdio MCP servers via npx, while the UBI HOME is not owned by that uid.
@@ -217,6 +217,7 @@ LABEL org.opencontainers.image.authors=['Langflow'] \
       org.opencontainers.image.source=https://github.com/langflow-ai/langflow
 
 ENV PATH="/app/.venv/bin:$PATH" \
+    HOME=/app/data \
     BASH_ENV="" \
     ENV="" \
     PROMPT_COMMAND="" \

docker/build_and_push.Dockerfile

@@ -86,6 +86,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=""
@@ -101,7 +102,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

@@ -130,6 +130,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=""
@@ -141,7 +142,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

@@ -15,7 +15,7 @@ When `enabled` is `true`, you must supply at least one policy before generating
 Generated guard code is written under `tmp_toolguard/{user}/{flow}/{component}/{project}/`, with **Step 1** producing guard specifications from policies in `Step_1/`, and **Step 2** turning those specifications into executable guard code in `Step_2/`.
 These namespaces prevent different users, flows, or Policies components with the same project name from sharing generated guards.
 When no flow context is available, the component uses the stable `standalone` flow namespace; when no user is available, it uses `anonymous`.
-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. The component handles module caching and cleanup automatically.
 
 For more information, see the [ToolGuard GitHub repository](https://github.com/AgentToolkit/toolguard).
 
@@ -24,7 +24,7 @@ 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. Project namespace for generated code under `tmp_toolguard/{user}/{flow}/{component}/` (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. |

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.

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). |

docs/docs/Develop/environment-variables.mdx

@@ -170,7 +170,13 @@ If Langflow fails to start with a `get_body_field` error after installing versio
 
     For more information, see [Docker image defaults](/deployment-docker#docker-image-security-defaults).
 
-- Long-tail component bundles are now opt-in
+ - Docker runtime home moved to `/app/data`
+
+    Patched 1.11 Docker images set `HOME=/app/data` so the non-root runtime user has a writable home directory.
+    When `LANGFLOW_CONFIG_DIR` isn't set, the default config directory therefore changes from `/opt/app-root/src/.cache/langflow` to `/app/data/.cache/langflow`; SQLite follows that directory when `LANGFLOW_SAVE_DB_IN_CONFIG_DIR=true`.
+    Persist `/app/data` or set `LANGFLOW_CONFIG_DIR` to your existing writable data directory before upgrading to preserve existing data.
+
+ - Long-tail component bundles are now opt-in
 
     Starting in Langflow 1.11.x, `pip install langflow` no longer installs the long-tail providers in the `lfx-bundles` metapackage.
     If an existing flow uses components such as Chroma, Ollama, Qdrant, Redis, PGVector, Tavily, Wikipedia, MongoDB, Weaviate, or Milvus, install the metapackage in the same environment after upgrading:

docs/docs/Support/release-notes.mdx

@@ -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. |
-