mirror of
https://github.com/OpenHands/OpenHands.git
synced 2025-12-26 05:48:36 +08:00
* feat: Initial work on security analyzer * feat: Add remote invariant client * chore: improve fault tolerance of client * feat: Add button to enable Invariant Security Analyzer * [feat] confirmation mode for bash actions * feat: Add Invariant Tab with security risk outputs * feat: Add modal setting for Confirmation Mode * fix: frontend tests for confirmation mode switch * fix: add missing CONFIRMATION_MODE value in SettingsModal.test.tsx * fix: update test to integrate new setting * feat: Initial work on security analyzer * feat: Add remote invariant client * chore: improve fault tolerance of client * feat: Add button to enable Invariant Security Analyzer * feat: Add Invariant Tab with security risk outputs * feat: integrate security analyzer with confirmation mode * feat: improve invariant analyzer tab * feat: Implement user confirmation for running bash/python code * fix: don't display rejected actions * fix: make confirmation show only on assistant messages * feat: download traces, update policy, implement settings, auto-approve based on defined risk * Fix: low risk not being shown because it's 0 * fix: duplicate logs in tab * fix: log duplication * chore: prepare for merge, remove logging * Merge confirmation_mode from OpenDevin main * test: update tests to pass * chore: finish merging changes, security analyzer now operational again * feat: document Security Analyzers * refactor: api, monitor * chore: lint, fix risk None, revert policy * fix: check security_risk for None * refactor: rename instances of invariant to security analyzer * feat: add /api/options/security-analyzers endpoint * Move security analyzer from tab to modal * Temporary fix lock when security analyzer is not chosen * feat: don't show lock at all when security analyzer is not enabled * refactor: - Frontend: * change type of SECURITY_ANALYZER from bool to string * add combobox to select SECURITY_ANALYZER, current options are "invariant and "" (no security analyzer) * Security is now a modal, lock in bottom right is visible only if there's a security analyzer selected - Backend: * add close to SecurityAnalyzer * instantiate SecurityAnalyzer based on provided string from frontend * fix: update close to be async, to be consistent with other close on resources * fix: max height of modal (prevent overflow) * feat: add logo * small fixes * update docs for creating a security analyzer module * fix linting * update timeout for http client * fix: move security_analyzer config from agent to session * feat: add security_risk to browser actions * add optional remark on combobox * fix: asdict not called on dataclass, remove invariant dependency * fix: exclude None values when serializing * feat: take default policy from invariant-server instead of being hardcoded * fix: check if policy is None * update image name * test: fix some failing runs * fix: security analyzer tests * refactor: merge confirmation_mode and security_analyzer into SecurityConfig. Change invariant error message for docker * test: add tests for invariant parsing actions / observations * fix: python linting for test_security.py * Apply suggestions from code review Co-authored-by: Engel Nyst <enyst@users.noreply.github.com> * use ActionSecurityRisk | None intead of Optional * refactor action parsing * add extra check * lint parser.py * test: add field keep_prompt to test_security * docs: add information about how to enable the analyzer * test: Remove trailing whitespace in README.md text --------- Co-authored-by: Mislav Balunovic <mislav.balunovic@gmail.com> Co-authored-by: Engel Nyst <enyst@users.noreply.github.com> Co-authored-by: Xingyao Wang <xingyao6@illinois.edu>
OpenDevin Architecture
This directory contains the core components of OpenDevin.
This diagram provides an overview of the roles of each component and how they communicate and collaborate.

Classes
The key classes in OpenDevin are:
- LLM: brokers all interactions with large language models. Works with any underlying completion model, thanks to LiteLLM.
- Agent: responsible for looking at the current State, and producing an Action that moves one step closer toward the end-goal.
- AgentController: initializes the Agent, manages State, and drive the main loop that pushes the Agent forward, step by step
- State: represents the current state of the Agent's task. Includes things like the current step, a history of recent events, the Agent's long-term plan, etc
- EventStream: a central hub for Events, where any component can publish Events, or listen for Events published by other components
- Event: an Action or Observeration
- Action: represents a request to e.g. edit a file, run a command, or send a message
- Observation: represents information collected from the environment, e.g. file contents or command output
- Event: an Action or Observeration
- Runtime: responsible for performing Actions, and sending back Observations
- Sandbox: the part of the runtime responsible for running commands, e.g. inside of Docker
- Server: brokers OpenDevin sessions over HTTP, e.g. to drive the frontend
- Session: holds a single EventStream, a single AgentController, and a single Runtime. Generally represents a single task (but potentially including several user prompts)
- SessionManager: keeps a list of active sessions, and ensures requests are routed to the correct Session
Control Flow
Here's the basic loop (in pseudocode) that drives agents.
while True:
prompt = agent.generate_prompt(state)
response = llm.completion(prompt)
action = agent.parse_response(response)
observation = runtime.run(action)
state = state.update(action, observation)
In reality, most of this is achieved through message passing, via the EventStream. The EventStream serves as the backbone for all communication in OpenDevin.
flowchart LR
Agent--Actions-->AgentController
AgentController--State-->Agent
AgentController--Actions-->EventStream
EventStream--Observations-->AgentController
Runtime--Observations-->EventStream
EventStream--Actions-->Runtime
Frontend--Actions-->EventStream
Runtime
The Runtime class is abstract, and has a few different implementations:
- We have a LocalRuntime, which runs commands and edits files directly on the user's machine
- We have a DockerRuntime, which runs commands inside of a docker sandbox, and edits files directly on the user's machine
- We have an E2BRuntime, which uses e2b.dev containers to sandbox file and command operations