openxflow
AGENTS.md8 starsChanged 3 months agoMITView on GitHub
Langflow is a visual workflow builder for AI-powered agents. It has a Python/FastAPI backend, React/TypeScript frontend, and a lightweight executor CLI (lfx). For component development, enable dynamic loading: The public dependency direction is langflow → langflow-core → langflow-base → lfx. Provider packages under src/bundles/ are added only by the full langflow distribution. Authorization is a pluggable layer separate from authentication:
1 other project uses a version of this.
Adopted by
Most recently taken up by
- langflow-ai/langflowword for word, first seen Oct 8, 2026
Other versions1 project uses a version of this.
Word for word · 1
- langflow-ai/langflow★ 156k100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.
Of the AGENTS.md files we read, the 31,774 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.
In this repository13 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- .cursor/rules/docs_development.mdcCursor rule
- backend-code-reviewSkill
- component-refactoringSkill
- e2e-testingSkill
- frontend-code-reviewSkill
- frontend-i18nSkill
- frontend-query-mutationSkill
- frontend-testingSkill
- ibm-a11y-level1-auditSkill
- ibm-a11y-pr-remediationSkill
- ibm-a11y-route-scanSkill
- ibm-a11y-testing-guideSkill
The file
Show its rules and text
We split this AGENTS.md into the rules it gives an agent
15 rules. About 0 are common, 4 are distinctive, and 11 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
11
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 112
Default is off: LANGFLOW_AUTHZ_ENABLED=false.
- Very specific: line 142
Create component class inheriting from Component
- Very specific: line 144
Add to __init__.py (alphabetical order)
- Very specific: line 145
Run with LFX_DEV=1 make backend for hot reload
- Very specific: line 186
Create SVG component in src/frontend/src/icons/YourIcon/
- Very specific: line 197
Always use uv run when running Python commands
- Very specific: line 198
When running tests inside a sub-package (e.g.
- Very specific: line 205
Call async_start and iterate over the results
- Distinctive: line 210
Avoid mocking in tests when possible
- Distinctive: line 211
Prefer real integrations for more reliable tests
- Very specific: line 226
Run make format_backend once before staging - fixes most ruff issues up front.
- Very specific: line 227
Run uv run git commit (the uv run ensures pre-commit finds the right Python).
- Very specific: line 228
If you touched backend code, run make unit_tests locally for faster feedback than CI.
- Distinctive: line 232
Follow semantic commit conventions
- Distinctive: line 234
Ensure all tests pass before submitting
≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
AGENTS.md
This file provides guidance to AI coding agents when working with code in this repository.
Project Overview
Langflow is a visual workflow builder for AI-powered agents. It has a Python/FastAPI backend, React/TypeScript frontend, and a lightweight executor CLI (lfx).
Prerequisites
- Python: 3.10-3.14
- uv: >=0.4 (Python package manager)
- Node.js: >=20.19.0 (v22.12 LTS recommended)
- npm: v10.9+
- make: For build coordination
Common Commands
Development Setup
make init # Install all dependencies + pre-commit hooks
make run_cli # Build and run Langflow (http://localhost:7860)
make run_clic # Clean build and run (use when frontend issues occur)Development Mode (Hot Reload)
make backend # FastAPI on port 7860 (terminal 1)
make frontend # Vite dev server on port 3000 (terminal 2)For component development, enable dynamic loading:
LFX_DEV=1 make backend # Load all components dynamically
LFX_DEV=mistral,openai make backend # Load only specific modulesCode Quality
make format_backend # Format Python (ruff) - run FIRST before lint
make format_frontend # Format TypeScript (biome)
make format # Both
make lint # mypy type checkingTesting
make unit_tests # Backend unit tests (pytest, parallel)
make unit_tests async=false # Sequential tests
uv run pytest path/to/test.py # Single test file
uv run pytest path/to/test.py::test_name # Single test
make test_frontend # Jest unit tests
make tests_frontend # Playwright e2e testsDatabase Migrations
make alembic-revision message="Description" # Create migration
make alembic-upgrade # Apply migrations
make alembic-downgrade # Rollback one versionArchitecture
Monorepo Structure
src/
├── backend/
│ ├── base/langflow/ # Core backend package (langflow-base)
│ │ ├── api/ # FastAPI routes (v1/, v2/)
│ │ ├── components/ # Built-in Langflow components
│ │ ├── services/ # Service layer (auth, database, cache, etc.)
│ │ ├── graph/ # Flow graph execution engine
│ │ └── custom/ # Custom component framework
│ └── tests/ # Backend tests
├── frontend/ # React/TypeScript UI
│ └── src/
│ ├── components/ # UI components
│ ├── stores/ # Zustand state management
│ └── icons/ # Component icons
├── langflow-core/ # Usable provider-free Langflow distribution
├── bundles/ # Curated provider integrations
└── lfx/ # Lightweight executor and shared primitivesKey Packages
- langflow: Full end-user package; depends on
langflow-coreand curated provider bundles - langflow-core: Service-complete, provider-bundle-free distribution; owns the
langflowCLI - langflow-base: Modular application platform (API, services, graph engine); extras add service integrations
- lfx: Shared execution primitives and standalone CLI (
lfx serve,lfx run)
The public dependency direction is langflow → langflow-core → langflow-base → lfx.
Provider packages under src/bundles/ are added only by the full langflow distribution.
Service Layer
Backend services in src/backend/base/langflow/services/:
auth/- Authenticationauthorization/- Authorization (RBAC) plugin layer — see belowdatabase/- SQLAlchemy models and migrationscache/- Caching layerstorage/- File storagetracing/- Observability integrations
Authorization (RBAC)
Authorization is a pluggable layer separate from authentication:
- OSS ships the interface (
BaseAuthorizationServiceinlfx) + a pass-through implementation (LangflowAuthorizationService) + theauthz_*andcasbin_ruleDB schema + route guards. - Implementations register via the
lfx.servicesentry pointauthorization_serviceinlfx.toml(same pattern as the SSOauth_service). A registered plugin reads theauthz_*admin tables and writes compiled rules tocasbin_rule.
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.
Route guards live in langflow.services.authorization.guards (the legacy langflow.services.authorization.utils path re-exports them for backward compatibility):
ensure_flow_permission(user, FlowAction.*, flow_id=..., flow_user_id=..., workspace_id=..., folder_id=...)— single-flow CRUD + executeensure_deployment_permission(user, DeploymentAction.*, deployment_id=..., deployment_user_id=..., workspace_id=..., project_id=...)ensure_project_permission(user, ProjectAction.*, project_id=..., project_user_id=..., workspace_id=...)ensure_knowledge_base_permission(user, KnowledgeBaseAction.*, kb_name=..., kb_user_id=...)ensure_variable_permission(user, VariableAction.*, variable_id=..., variable_user_id=...)ensure_file_permission(user, FileAction.*, file_id=..., file_user_id=...)ensure_share_permission(user, ShareAction.*, share_id=..., share_user_id=...)filter_visible_resources(user, resource_type=..., candidates=..., act=...)— list-endpoint filter; safe no-op in OSS
The enforcement request shape is (subject, domain, object, action):
- subject =
user:{uuid} - domain =
project:{uuid}→workspace:{uuid}→*(resolved by_resolve_flow_domain; the more specific domain wins so project-scoped grants match directly while workspace-scoped grants still flow down via plugin-side role inheritance) - object =
flow:{uuid}/deployment:{uuid}/project:{uuid}/flow:*/ etc. - action =
read/write/create/delete/execute/deploy
Share-aware fetch (Phase 3): route fetch helpers (_read_flow, get_flow_by_id_or_endpoint_name, get_deployment, project reads in projects.py, v2 file fetcher, variable PATCH/DELETE in variable.py) branch on BaseAuthorizationService.supports_cross_user_fetch(). The OSS pass-through reports False so the existing owner-scoped queries are preserved — enabling LANGFLOW_AUTHZ_ENABLED=true without a registered plugin cannot widen visibility. Plugins set SUPPORTS_CROSS_USER_FETCH=True so resources load by id alone and ensure_*_permission decides access; route handlers can convert a plugin-deny HTTPException(403) to HTTPException(404) via langflow.services.authorization.fetch.deny_to_404 to preserve UUID privacy.
Share CRUD API (Phase 3): /api/v1/authz/shares provides POST / GET / PATCH / DELETE on authz_share rows. The handler enforces an OSS floor (resource owner or superuser may administer shares for that resource) so the OSS pass-through cannot let a non-owner mint share rows. Each write fires BaseAuthorizationService.invalidate_user / invalidate_all so a registered enforcer can drop cached policy. Audit rows are written via audit_decision with share:create / share:update / share:delete actions.
Audit query API (Phase 4): GET /api/v1/authz/audit (superuser-only) exposes a paginated, filterable view of authz_audit_log. Supports user_id, resource_type, resource_id, action, result, since, until filters; page size capped at 200.
Default role catalog (Phase 4): the consolidated foundations migration 7c8d9e0f1a2b_authz_foundations seeds the three built-in is_system=True roles (viewer / developer / admin) with "{resource}:{action}" permission slugs. OSS does not interpret these — they exist so a registered plugin's policy sync has a stable bootstrap source.
Component Development
Components live in src/backend/base/langflow/components/. To add a new component:
- Create component class inheriting from
Component - Define
display_name,description,icon,inputs,outputs - Add to
__init__.py(alphabetical order) - Run with
LFX_DEV=1 make backendfor hot reload
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.
Component Structure
from langflow.custom import Component
from langflow.io import MessageTextInput, Output
class MyComponent(Component):
display_name = "My Component"
description = "What it does"
icon = "component-icon" # Lucide icon name or custom
inputs = [
MessageTextInput(name="input_value", display_name="Input"),
]
outputs = [
Output(display_name="Output", name="output", method="process"),
]
def process(self) -> Message:
# Component logic
return Message(text=self.input_value)Component Testing
Tests go in src/backend/tests/unit/components/. Use base classes:
ComponentTestBaseWithClient- Components needing API accessComponentTestBaseWithoutClient- Pure logic components
Required fixtures: component_class, default_kwargs, file_names_mapping
Frontend Development
- React 19 + TypeScript + Vite
- Zustand for state management
- @xyflow/react for graph visualization
- Tailwind CSS for styling
Custom Icons
- Create SVG component in
src/frontend/src/icons/YourIcon/ - Export with
forwardRefandisDarkprop support - Add to
lazyIconImports.ts - Set
icon = "YourIcon"in Python component
Testing Notes
@pytest.mark.api_key_required- Tests requiring external API keys@pytest.mark.no_blockbuster- Skip blockbuster plugin- Database tests may fail in batch but pass individually
- Pre-commit hooks require
uv run git commit - Always use
uv runwhen running Python commands - 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 defaultuv synconly resolves the top-level workspace and may leave dev-only test deps (e.g.fakeredis) uninstalled.
Graph Testing Pattern
Proper Graph tests follow this pattern:
- Build graph with connected components
- Connect them via
.set()calls - Call
async_startand iterate over the results - Validate the results
Testing Best Practices
- Avoid mocking in tests when possible
- Prefer real integrations for more reliable tests
Version Management
make patch v=1.5.0 # Update version across all packagesThis updates: pyproject.toml, src/backend/base/pyproject.toml, src/frontend/package.json
Pre-commit Workflow
Pre-commit hooks run ruff and biome automatically on git commit, so manual
formatting is not required. To avoid an extra commit cycle when you have many
changes:
- Run
make format_backendonce before staging - fixes most ruff issues up front. - Run
uv run git commit(theuv runensures pre-commit finds the right Python). - If you touched backend code, run
make unit_testslocally for faster feedback than CI.
Pull Request Guidelines
- Follow semantic commit conventions
- Reference any issues fixed (e.g.,
Fixes #1234) - Ensure all tests pass before submitting
Documentation
Documentation uses Docusaurus and lives in docs/:
cd docs
yarn install
yarn start # Dev server on port 3000 (prompts for 3001 if 3000 is in use)Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

