Open SWE: LangChain's coding agent factory is open source, but self hosting it means Managed Deep Agents or a fork

Running it unchanged requires Managed Deep Agents

The code is open and the repository includes an installation guide at docs/INSTALLATION.md, but deploying Open SWE as is requires Managed Deep Agents, a LangSmith service that runs the agent. Without it, the maintainers advise forking and adapting the code to your own runtime.

The dependency shows up in the code too. pyproject.toml pulls in managed-deepagents>=0.10.0 for the types of event requests the MDA deployment's channels send, and standardwebhooks>=1.1.0 to verify the signature MDA puts on those requests using MDA_SERVICE_SECRET. There is an mda/ directory at the top level. For a team that wants to keep everything on its own infrastructure without a LangChain managed service, Open SWE is a starting point for a port, not something you can install and run.

No issues, no outside contributions, no compatibility promise

The project marks itself as under active development and tells readers to expect breaking changes and rough edges. It is not accepting issues or external contributions at this time. Forking is welcome, but correctness, stability and compatibility are not guaranteed.

Activity backs this up: the last push was on 2026-11-02, and desktop nightly builds such as desktop-v0.3.11-nightly.20261103081604 are being tagged several times a day. That pace is good for people tracking LangChain's direction and bad for anyone who needs a fixed target. If you fork, you own the merge work each time you pull upstream, and you cannot file a bug report to get a fix. Budget for maintaining your fork as your own code.

Deep Agents and LangGraph do the agent work

Open SWE is a layer on top of two LangChain projects. Deep Agents supplies the planning, filesystem, shell, skills and subagent primitives. LangGraph provides durable execution and thread state. Open SWE adds engineering tools, integrations, authorization and the user interfaces. Graph entrypoints are declared in langgraph.json, and AGENTS.md carries an architecture inventory.

The Dockerfile builds on langchain/langgraph-api:0.15.1-py3.14 and registers three graphs:

ENV LANGSERVE_GRAPHS='{"agent":"openswe.graphs.agent:traced_agent","reviewer":"openswe.graphs.reviewer:traced_reviewer_agent","review-scout":"openswe.graphs.review_scout:traced_review_scout"}'

The image also strips pip, setuptools, wheel and uv after installing dependencies, and exposes port 8000. Deep Agents is pinned exactly at deepagents==0.7.32, with an explicit langchain-core>=1.7.3,<2 dependency that a comment says will be removed after upgrading to deepagents 0.7.33.

Per-thread sandboxes that are never silently swapped

Cloud coding runs in persistent Linux sandboxes, one per thread, with tooling supplied by workspace scripts or snapshots. A follow-up in the same thread reuses that thread's context and sandbox, while independent threads can run in parallel. If a coding sandbox becomes unreachable, Open SWE does not quietly replace it with a fresh one, so a broken sandbox surfaces as a failure rather than as work continuing on a different machine state.

LangSmith is the default provider for both sandboxes and tracing. Other providers and local execution can be configured through the sandbox section of docs/CUSTOMIZATION.md. The trade off with local execution is explicit: it does not provide cloud sandbox isolation, so the agent's shell runs with whatever access your machine has. PR chat, which is read only, does not need a sandbox at all.

Coding sandboxes get installation-wide GitHub access by default

The security model has gaps you need to close yourself. Coding sandboxes normally receive installation-wide GitHub App access; only selected workflows use narrower repository scopes. Workspace repository bindings decide routing and which checkouts are preloaded, but they are not a separate credential boundary, so binding a workspace to one repository does not stop the sandbox from reaching others the app is installed on.

Approval prompts are similarly narrow. Workflow-file approval prompts guard detected Git pushes, not every possible shell or API write. Reviewers are instructed not to commit or push, and PR chat leaves out mutation tools, but an instruction is not an enforcement mechanism. Sandboxes may have network access. Install the GitHub App on as few repositories as possible, use least privilege credentials, and tune approval policies before pointing it at production code.

Python 3.14 and a local Postgres are part of the stack

The Python package, open-swe-agent 0.1.0, sets requires-python = ">=3.14". Teams standardised on an older interpreter will need a separate environment, and the Dockerfile base image is also a py3.14 build. The repository uses uv for Python (there is a uv.lock) and pnpm with turbo for the JavaScript side, with packageManager pinned to [email protected].

Persistence relies on SQLAlchemy, asyncpg and Alembic, and compose.yaml starts a Postgres 16 container bound only to the loopback address:

    ports:
      - "127.0.0.1:5433:5432"

The compose file sets POSTGRES_PASSWORD to postgres, which is fine for a laptop and unacceptable anywhere shared. The end to end tests use Playwright, installed through this script:

    "test:e2e:install": "pnpm --filter open-swe-e2e exec playwright install --with-deps chromium",

Work starts from GitHub, Slack, Linear or the dashboard

Open SWE takes tasks from issues, conversations, PRs and schedules, plans and investigates, implements in an isolated sandbox, validates and delivers a PR, then handles review, CI and feedback, looping back for follow up work. You can start or continue from the dashboard, GitHub issues and PR conversations, or Slack. In Linear, mentioning or delegating an issue to the Open SWE app opens an agent session.

Beyond writing code, it runs on demand or opt in automatic PR reviews, publishes findings to GitHub and learns repository specific review preferences from past feedback. The /baby-sit command monitors opted in PRs, diagnoses failures and reruns only flaky jobs that have evidence behind them. Models, reasoning effort, instructions, skills, MCP integrations and sandbox providers are all configurable, and there are separate Slack flows for human review and expedited approval of small pull requests.

The vendor/ directory is outside the MIT license

Open SWE's own code is MIT licensed, but that license stops at the vendor/ directory. Anything under vendor/ is not licensed by this repository at all, and vendor/README.md is where to read about it. A comment in pyproject.toml ties at least part of it to the deployment: the event request types come from the vendored SDK that the MDA deployment runs.

For a company forking Open SWE, this matters before any code ships. Your legal review cannot treat the repository as uniformly MIT. Check what vendor/ contains, under what terms it is available, and whether your fork can drop or replace it if you move away from Managed Deep Agents.

Editorial conclusion

Open SWE suits teams already on LangChain's stack who want an internal coding agent and are willing to run Managed Deep Agents, or engineers who plan to fork the code and adapt it to their own runtime. It does not suit anyone who needs a stable, supported product: the maintainers promise no correctness, stability or compatibility and accept no issues. Before adopting it, confirm you can run Python 3.14, decide how you will scope the GitHub App's installation-wide access, and check what lives under vendor/, since that code is not covered by the MIT license.

Frequently asked questions

Official sources

1. langchain-ai/open-swe on GitHub
2. License: MIT
3. Project website
4. README
5. Releases