Langflow

Build AI applications with visual workflows and Python components.

Authorization flags and component class names carry contracts that a routine refactor can break.

Documents

├── 
├──  · imports AGENTS.md, .claude/CLAUDE.md (unavailable)
└── .claude
    └── CLAUDE.md · unavailable at this commit

The file, explained

What makes it useful

Langflow describes a layered Python backend alongside its frontend and component system. The architecture notes explain dependency direction and distinguish the shipped authorization interface from a plugin that actually denies access. Development guidance protects class names stored in saved flows and maps work to the appropriate package environment and tests.

Techniques in this file

Quoted passages are verbatim. Open one to see it in the source.

01 / Architecture as narrative

Make dependency direction explicit

The package chain gives an agent a way to judge where new imports and provider integrations belong. Architecture is described as a dependency constraint, beyond a directory listing.

Source excerpt starting at line 93.
The public dependency direction is `langflow → langflow-core → langflow-base → lfx`.

02 / Architecture as narrative

Distinguish a switch from enforcement

The authorization notes explain that enabling the interface alone does not introduce a deny policy. An agent changing permission-sensitive behavior must account for the registered implementation.

Source excerpt starting at line 112.
Default is **off**: `LANGFLOW_AUTHZ_ENABLED=false`. When enabled with only the OSS stub registered, every check returns allow — the stub is a no-op so routes stay wired and audit rows still flow. Real allow/deny requires a registered authorization plugin.

03 / Hard prohibitions

Protect identifiers stored in user data

Class names are part of saved-flow compatibility. A rename that looks local in Python can break existing documents, so the instruction calls it out as a persistent contract.

Source excerpt starting at line 147.
**IMPORTANT:** Changing a component's class name is a breaking change and should never be done. The class name serves as an identifier used to match components in saved flows and to flag them for updates in the UI. Renaming it will break existing flows that use that component.

04 / Verification by change type

Include the subpackage development environment

The test setup names the package whose development dependencies must be synchronized. A root install is not evidence that component test dependencies are present.

Source excerpt starting at line 198.
- When running tests inside a sub-package (e.g. `langflow-base`, `lfx`), sync that package's dev group first: `uv sync --group dev --package langflow-base`. The default `uv sync` only resolves the top-level workspace and may leave dev-only test deps (e.g. `fakeredis`) uninstalled.

Put it to work

Borrow this for your repo

  1. Write the allowed dependency direction as an explicit chain.
  2. Document when a feature flag enables an interface without enforcing a policy.
  3. Identify code names that are serialized into user data.
  4. Include package-specific dependency setup beside test commands.

How the file is organized

  1. 01Project Overview
  2. 02Prerequisites
  3. 03Common Commands
  4. 04Architecture
  5. 05Component Development
  6. 06Frontend Development
  7. 07Testing Notes
  8. 08Version Management
  9. 09Pre-commit Workflow
  10. 10Pull Request Guidelines
  11. 11Documentation
Read this revision on GitHub ↗

Context your instructions cannot carry

Langflow's file tells an agent how the codebase works. It cannot tell it which bug three customers hit this week. Modem keeps that context current and attaches it to the work.

Try Modem