# OpenInspect documentation (/)





OpenInspect is a background coding agent. You describe a piece of work, the agent runs it in an isolated cloud sandbox with a full development environment, and you come back to review the result: a response, a diff, and usually a pull request.

<img alt="The OpenInspect home screen with the session inbox on the left and the new-session composer in the middle" src="__img0" title="The home screen: inbox on the left, composer with repository, branch, model, and skills pickers in the middle." />

The agent does not need you to stay connected. Send a prompt from the web app, Slack, a GitHub pull request, a Linear issue, or an automation, close the tab, and check the session later. Several people can watch and prompt the same session at the same time, and every commit is attributed to the person who asked for it.

## Start here [#start-here]

<Cards>
  <Card title="Quickstart" href="/getting-started/quickstart" description="Sign in, start a session against a repository, and read the first result." />

  <Card title="Your first pull request" href="/getting-started/first-pull-request" description="Ask the agent for a pull request, see how it is created, and review it like any other." />

  <Card title="Writing prompts that work" href="/prompting/writing-prompts" description="Give the agent a bounded task, the context it needs, and a definition of done." />

  <Card title="Automations" href="/automations" description="Start sessions on a schedule or when a webhook, GitHub, Slack, or Sentry event arrives." />
</Cards>

## One lifecycle [#one-lifecycle]

Every session, whether it starts from the web composer, a Slack message, or an automation, follows the same path.

<Mermaid
  chart="flowchart TB
    accTitle: OpenInspect architecture from request to reviewed pull request
    You([You])
    You --> Web[Web app] & Slack[Slack] & GH[GitHub PR] & Linear[Linear] & Auto[Automation]
    Web & Slack & GH & Linear & Auto --> CP[Control plane: session record and timeline]
    CP -->|dispatch prompt| Boot
    subgraph Sandbox[&#x22;Isolated sandbox&#x22;]
        Boot[Clone and boot] --> Agent[Agent edits, runs commands, validates]
    end
    Agent -.->|events stream back| CP
    CP -.-> Watch([You watch the timeline and changes])
    Agent -->|push branch, open PR| PR[Pull request on your repository]
    PR --> Review([You review and merge])"
/>

From your side, each session comes down to four actions:

1. **Choose** a target: a single repository and branch, an ad-hoc set of up to 10 repositories, a saved environment, or no repository at all.
2. **Describe** the work in one prompt: the goal, the constraints, and how the agent should prove it is done. Images can be attached.
3. **Review** the timeline, the final response, and **Changes** (the diff compared with session start), plus the tests or screenshots the agent produced.
4. **Iterate**: send another prompt on the same branch, ask for a pull request, or open the sandbox terminal and code server and finish the work yourself.

## Capability map [#capability-map]

| Area           | What it covers                                                                                                              | Start with                                           |
| -------------- | --------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------- |
| Sessions       | The session page, follow-ups and stopping, reviewing diffs, sandbox tools, sharing, child sessions, statuses, and recovery. | [Session page](/sessions/session-page)               |
| Prompting      | When to delegate, how to write a prompt the agent can finish, templates, and workflow recipes.                              | [When to delegate](/prompting/when-to-delegate)      |
| Configuration  | Lifecycle scripts, environments, prebuilt images, secrets, sandbox settings, source control, skills, MCP servers.           | [Lifecycle scripts](/configure/lifecycle-scripts)    |
| Models         | Choosing a model and reasoning effort, the two agent harnesses, and provider accounts.                                      | [Choosing a model](/models/choosing-a-model)         |
| Automations    | Sessions started by a schedule, an inbound webhook, a GitHub event, a Slack message, or a Sentry alert.                     | [Automations](/automations)                          |
| Integrations   | Slack, GitHub (reviews, mentions, PR Feedback Autofix), and Linear.                                                         | [Integrations](/integrations)                        |
| Administration | Workspace access and roles, the audit log, analytics, data controls, security, and deployment.                              | [Workspace access](/administration/workspace-access) |

## Where people stay in control [#where-people-stay-in-control]

The agent proposes changes; it does not merge them. Pull requests it opens are ordinary pull requests on your repository, authored as the person who asked for them when that person signed in with GitHub. Branch protection, required reviews, status checks, and your merge policy apply exactly as they do to a pull request a colleague opened. Every session is visible to the workspace, every prompt is attributed to its author, and administrators can read the audit log to see who did what.