Open SWE is an open-source framework for building an organization’s internal asynchronous coding agent. A developer can mention a bot in Slack, Linear or GitHub; the service assembles issue/thread context, creates a persistent cloud sandbox, clones a repository, plans and edits code, runs commands, commits to a branch and opens or updates a draft pull request.
It is not a hosted coding service that becomes safe after installation. Open SWE is a reference architecture built on LangGraph and Deep Agents. The operator must select models and sandbox providers, create GitHub/Slack/Linear applications, secure the deployment, scope repositories and tokens, add deterministic validation, control network access and own every resulting pull request.
The end-to-end architecture
| Layer | Published role | Decision the operator owns |
|---|---|---|
| Invocation | Slack mention, Linear comment or GitHub PR comment | Who can trigger which repositories and at what cost |
| Context | AGENTS.md plus full issue or thread history | Which content is trusted, redacted or prompt-injection-prone |
| Harness | Deep Agents composed inside LangGraph | Model, system prompt, tools, middleware and call limits |
| Sandbox | Persistent remote Linux environment per task | Provider, image, egress, lifetime, resources and data location |
| Tools | Shell, files, HTTP, Slack, Linear, GitHub and optional observability | Least privilege, side-effect approvals and secret boundaries |
| Orchestration | Subagents and deterministic middleware hooks | Concurrency, budget, shared state and error handling |
| Delivery | Commit, push, draft PR and source-channel reply | CI, reviewers, merge policy and deployment separation |
Sandboxing reduces host risk, not external authority
The repository says each task receives an isolated cloud sandbox with full shell permissions and no confirmation prompts, and supports Modal, Daytona, Runloop, E2B and LangSmith sandboxes. A separate sandbox limits filesystem and process conflicts, but the README’s phrase that the blast radius is “fully contained” should not be treated literally.
The agent can have network egress, repository authority, package-registry access and external APIs. It may exfiltrate source, burn model credits, open harmful pull requests, abuse a token or attack internal services reachable from the sandbox. A sandbox-provider control-plane compromise can also cross task boundaries. Containment requires egress policy, short-lived credentials, quotas, provider isolation and an independent merge/deploy gate.
| Risk | Sandbox helps | Required companion control |
|---|---|---|
| Destructive shell command | Limits local disk/process damage to disposable environment | No production mounts; resource/time limits and clean teardown |
| Malicious dependency | Separates task from developer laptop | Lockfiles, registry allowlist, scanning and restricted egress |
| GitHub token misuse | Little if token permits external actions | Proxy/scoped app token limited to repo and branch operations |
| Prompt injection | May limit host compromise | Trust labels, tool policy and denial of sensitive systems |
| Bad code | Allows tests in an isolated runtime | Deterministic CI, security review and protected branches |
| Data leakage | Separates local workstation data | Provider/data review, redaction and outbound destination controls |
Issue and chat text are untrusted instructions
Open SWE injects the full Linear issue or Slack thread into agent context. That improves task comprehension but creates a direct prompt-injection path: an external reporter or copied log can instruct the agent to reveal secrets, fetch a malicious URL or change unrelated code. AGENTS.md is more authoritative, yet it is also repository content that a compromised branch can modify.
Mark content by provenance and trust level. System policy, organization rules and approved repository configuration should outrank ticket descriptions, comments, logs, web pages and code strings. Do not let an untrusted contributor trigger a run with observability or internal-data tools. The current project explicitly limits optional Datadog/LangSmith tools to authorized users; preserve and test that boundary.
Tool curation and credentials
The default tool set includes shell execution, file operations, URL fetch, arbitrary HTTP requests, Linear search/comments and Slack reactions/replies. GitHub operations can be proxied so the sandbox sees a dummy token while the server performs authorized requests. Optional Datadog, LangSmith and Corridor tools run server-side, keeping those credentials out of the sandbox.
| Tool group | Minimum permission | High-risk misuse |
|---|---|---|
| GitHub | Read code; push one task branch; open/update draft PR | Changing protections, secrets, releases or other branches |
| Slack/Linear | Read triggering thread/issue and reply there | Searching confidential discussions or mass messaging |
| HTTP/fetch | Allowlisted public documentation where possible | SSRF, metadata access, exfiltration and hostile page instructions |
| Observability | Read-only, scoped services and authorized users | Leaking customer data or secrets embedded in logs/traces |
| Shell | Full control only inside resource-limited sandbox | Fork bombs, cryptomining, network scanning or persistence |
| Subagents | Same or narrower authority than parent | Multiplying cost, conflicts and tool calls |
Validation is the biggest default gap
The README describes validation as prompt-driven: the agent is instructed to run linters, formatters and tests before committing. Instructions are not enforcement. An agent can skip expensive tests, misread output, weaken a test, mock away behavior or claim success after a timeout. The project itself recommends adding deterministic CI, visual verification or review gates.
Move acceptance outside the model loop. The service should not mark a task successful until required commands execute in a fresh environment and return expected machine-readable results. The agent must not edit the workflow that determines its own pass state unless that workflow change is separately reviewed.
| Gate | Independent evidence | Failure policy |
|---|---|---|
| Scope | Changed paths compared with issue allowlist | Block PR update or request human exception |
| Build/typecheck | Fresh checkout command and exit code | Attach logs and mark incomplete |
| Tests | Required suites plus changed-test review | No retry loop that silently edits expectations |
| Security | Dependency, secret and static-analysis scanners | Quarantine finding; never auto-dismiss |
| Visual | Screenshot comparison at defined routes/viewports | Human approval for meaningful diffs |
| Reviewability | Diff size, summary, risk and rollback fields | Split oversized or mixed-concern changes |
Persistent threads need lifecycle rules
Follow-up Slack/Linear messages route to the same deterministic thread and persistent sandbox. This preserves context but can also preserve compromised state, stale branches, downloaded secrets and runaway processes. Define maximum lifetime, idle timeout, disk quota and a “recreate from clean template” path. A reopened ticket weeks later should not silently resume an old unpatched environment.
Middleware injects queued messages before the next model call. Record which message changed the task, who sent it and whether scope expanded. If a follow-up requests a new repository, external system or production action, create a new authorization decision instead of treating it as ordinary conversational context.
Subagents: useful parallelism with nonlinear cost
Deep Agents can spawn child agents with their own middleware, todo lists and file operations. Use them only for independent read-heavy work such as locating tests, comparing APIs or reviewing a bounded diff. Multiple writers in one branch can overwrite assumptions and create a larger, less coherent change.
- Set a maximum child count, model-call limit, token budget and wall-clock deadline.
- Assign non-overlapping files or require one parent to serialize edits.
- Keep child permissions no broader than the parent.
- Make every child return evidence and uncertainty, not only prose conclusions.
- Charge all child activity to the originating task for cost measurement.
Deployment and dependency choices
Open SWE requires more than installing a Python package: backend, dashboard, LangGraph/LangSmith services, GitHub App/OAuth, invocation integrations, sandbox provider, model credentials and production hosting. The code is MIT licensed, but cloud sandboxes, models, observability and messaging platforms have separate pricing and data terms.
Pin the Open SWE commit and all dependency locks. Store application secrets in a managed secret system, rotate webhook secrets, validate signatures and reject replayed events. Separate development and production installations. A public webhook plus a powerful GitHub App is an attractive target.
Task selection
| Task | Suitability | Reason |
|---|---|---|
| Mechanical API migration | Good pilot | Clear patterns, bounded files and deterministic tests |
| Add missing unit tests | Good with review | Useful research, but tests can encode wrong behavior |
| Dependency update | Conditional | Needs changelog, security and compatibility review |
| Ambiguous product feature | Poor initial fit | Requirements and UX judgment dominate coding |
| Authentication redesign | High risk | Security architecture requires accountable expertise |
| Production incident | Poor autonomous fit | Time pressure and live authority magnify mistakes |
Measure accepted engineering work
Track task acceptance rate, reviewer minutes, CI pass on first independent run, reopened defects, security findings, sandbox minutes, model tokens and total cost per merged PR. Compare with a human baseline at similar task complexity. PR count and lines changed are output volume, not productivity.
Maintain a no-agent control group and a synchronous-agent group. Asynchronous agents may reduce interruption while increasing review batches. The useful question is whether lead time and accepted quality improve without transferring hidden workload to reviewers and platform engineers.
Alternatives
| Option | Best fit | Tradeoff versus Open SWE |
|---|---|---|
| Open SWE | Teams building a customizable internal async-agent platform | Significant integration, security and operational ownership |
| Codex / Claude Code | Synchronous developer-supervised terminal work | Less background workflow orchestration |
| GitHub Copilot coding agent | GitHub-native managed issue-to-PR flow | Less framework-level customization and different hosting model |
| Devin | Managed autonomous coding workspace | Commercial hosted platform and less internal control |
| OpenHands | Open-source coding-agent runtime and research | Different integration and orchestration focus |
| CI scripts/bots | Deterministic migrations, formatting and updates | Less flexible reasoning, often safer and cheaper for known tasks |
Frequently asked questions
Is Open SWE a hosted service?
It is an open-source framework. Operators deploy and configure it and purchase or run the required model, sandbox and integration services.
Which sandboxes are supported?
The current repository lists Modal, Daytona, Runloop, E2B and LangSmith, plus a customization path.
Does it support Slack, Linear and GitHub?
Yes. These are the primary documented invocation and follow-up surfaces.
Does a sandbox make full permissions safe?
No. It isolates local execution, but network, repository and external-account authority need separate controls.
Does it automatically verify code?
The default relies heavily on agent instructions to run checks. Teams should add deterministic external CI and review gates.
Is it open source?
Yes. The current repository is licensed under MIT.
Primary sources
- Official repository and architecture
- Official Open SWE application
- Official installation guide
- Official customization guide
- Official security policy
- LangGraph overview
- GitHub App security best practices
- OWASP prompt-injection guidance
Last reviewed July 25, 2026. Open SWE evolves quickly; pin the deployed revision and revalidate integrations, sandbox behavior, tools and security controls after upgrades.
