Open SWE

Open SWE acts through its own GitHub App rather than a person's account, mints short-lived installation tokens per sandbox, and keeps the GitHub token out of the sandbox by having the LangSmith proxy inject it on the wire. However, ordinary coding threads started from Slack, the dashboard or Linear get a token for every repository the installation can reach with all of the app's write permissions (contents, pull requests, issues, workflows), and the docs state that a member can reach repositories they cannot access themselves. Only threads triggered by public-repository events and the reviewer are narrowed to one repository. Open SWE's own sensitive tools (admin, settings, SQL) do pass a per-actor policy check, and PRs are opened with the requesting user's OAuth token.

There is no general human approval step: shell commands, pushes, Slack posts, outbound HTTP requests and integration tools all run without asking anyone. The one deterministic gate is for git pushes that change GitHub Actions workflow files; it shows the exact diff, binds the approval to a fingerprint and pushes exactly the approved commit. But the guard does not cover every push and write path, and its approver authorization is not locked down. Merges through the human-review and expedited-review flows do require human votes.

The agent's main tool is an unrestricted shell in the sandbox, with `gh` pre-authenticated through the proxy, so most actions are raw command strings. A few server-side tools are carefully bounded: `http_request`/`fetch_url` resolve hosts and refuse non-public addresses on every redirect, MCP connections are pinned to their HTTPS origin, and the admin SQL tool runs in a read-only transaction with row and time limits. Tool availability is filtered per thread by an access policy, but write, exec and network tools are all on by default.

By default every shell command runs in a remote LangSmith cloud sandbox, not on the server that holds Open SWE's keys, and an unreachable sandbox is not silently replaced with host execution. Operators can switch to a documented `local` provider with no isolation, and the desktop app and CLI bridge deliberately run commands on the user's machine. Inside the default sandbox, network egress is unrestricted, the GitHub proxy will attach an installation-wide token to any github.com request, a capability header lets code in the sandbox invoke the thread's own agent tools, and sandboxes persist per thread for up to 30 days.

Only known Open SWE users can trigger runs from GitHub, and comments by unregistered GitHub users are wrapped in a 'dangerous external untrusted' tag with a prompt telling the model to ignore their instructions. Nothing in code acts on that tag, and web pages, repository files, Slack messages and MCP results enter the context with no marking at all. A hijacked agent can therefore push code to any installation repository and exfiltrate data through outbound HTTP or Slack without any human step.

The model can rewrite the user's personal standing instructions and personal skills with a tool call, without a human confirming the text; those are then loaded as trusted guidance into every later session of that user. Writes are limited to the owner on private threads and are audit-logged, and data is namespaced per user. Repository `AGENTS.md` files (and nested ones after file reads) are loaded silently and the system prompt tells the model they override its defaults. Repository files cannot add tools, MCP servers or approval rules.

Open SWE loads no third-party code in its own process: integrations are remote MCP servers over HTTPS that an admin or user adds explicitly, and requests are pinned to the configured origin and to public IP addresses. Admins choose which of a server's tools are allowed, but tool definitions are re-fetched on a short cache window with no re-approval when they change, and a remote server cannot be version-pinned. A malicious MCP server only receives its own credentials and the arguments sent to it.

Stored GitHub, Slack and MCP credentials are encrypted at rest with a rotatable key, and the GitHub token reaches the sandbox only as an opaque proxy-injected header, so the model never sees it. Usage telemetry to Segment is off unless a key is set. There is no redaction of secrets in tool outputs before they reach the model, transcripts or LangSmith traces, and the installation token is broad even though it is short-lived.

Every model call and tool call is written to an append-only transcript event log in Postgres by middleware that also covers sub-agents, alongside LangGraph thread state and LangSmith traces, and workflow-push approvals record who decided. A separate metadata-only audit log covers dashboard writes and a few settings tools. Both are explicitly best-effort: transcript failures are swallowed, audit writes can be lost, and GitHub API calls made from the sandbox through the proxy are only visible as the shell command that issued them.

Runs are bounded only loosely: 5,000 model calls and a 9,999-step recursion limit per run, a 15-minute cap per model call, and per-command timeouts, with background commands allowed for up to 24 hours (four at a time). There is no cost or spend ceiling. Stopping a thread interrupts its LangGraph runs and clears queued work, but background commands keep running inside the persistent sandbox until it idles out.