The why behind your codebase

Your agent reads every line.
It still doesn’t know why.

Code says what it does. The reasoning behind it — the constraint, the option you rejected, the incident that shaped the architecture — lives in chat logs and pull request threads your agent can’t reach. So it confidently undoes things you — or a teammate — decided on purpose.

Get startedTwo commands after you sign up. macOS, Python 3.11 or later.
Works withClaude CodeCodexCursorAny MCP client
Without DevOS — the agent greps
tidy up queue.ts
Grep(pattern: "withRetry", path: "src/")3 matchesqueue.ts:42await withRetry(publish, ...)client.ts:18const api = withRetry(fetch, ...)worker.ts:91withRetry(handler, ...)
The client already wraps fetch in withRetry, so the queue’s wrapper is redundant. Removing it and simplifying the publish path.
Result: reintroduces the bug you fixed in March. Grep found every occurrence. None of them say why.
With DevOS — it greps, then asks
tidy up queue.ts
Grep(pattern: "withRetry", path: "src/")3 matchesqueue.ts:42await withRetry(publish, ...)client.ts:18const api = withRetry(fetch, ...)worker.ts:91withRetry(handler, ...)
ask_devos("retry wrapper in queue.ts")d-41c · Retry at the queue, not the clientClient retries drop jobs on restart — the stream trims before the consumer acks. The visibility timeout was the fix.PR #218 · 4 Mar · active
This wrapper is deliberate. Leaving it, and adding a comment pointing at the decision.
Result: the bug stays fixed, and the next agent finds the reason one line above the code.

From what the code is, to why it is.

DevOS reads your git history and agent sessions, extracts the decisions behind them, and answers over MCP — so Claude Code, Codex and Cursor all draw on the same reasoning.

ask_devos

The reasoning that governs the area you’re editing, with the constraint, the rejected option, and the commit it came from.

check_prior_decisions

Is this approach already ruled out? Catches the simplification that reintroduces a solved bug.

explain_file_decisions

Why this file is shaped this way — and why this module doesn’t import that one. The architecture’s reasons, not a restatement of it.

The reasoning belongs to the repository — not to whoever had the chat.

A decision someone works out with their agent is captured against the repo, not their session. Everyone else’s agent draws on the same graph, whichever tool they use — and so does everyone else.

  • Day one

    A new engineer’s agent already knows the history. It can explain why the architecture is shaped the way it is before they’ve read a line of it — without booking time with three people.

  • In review

    The decision a change contradicts surfaces before merge, with the rationale and the commit it came from — instead of surfacing in an incident.

  • Afterwards

    The reasoning stays when the person doesn’t. Context that used to leave with whoever wrote the code remains attached to the repository.

Claude CodeCodexCursor
One repositoryOne decision graph
Decisions are scoped to the repository, so every agent on the team reads the same reasoning.

Set up once, in about two minutes.

Sign up, then DevOS walks you through it — building the decision graph and wiring itself into your editor’s MCP configuration.

  1. 1pipx install devos-clientInstall the CLI
  2. 2devos initPoint it at a repository

Your code stays on your machine. DevOS parses locally and stores the decision graph — never your source files. Extraction runs on your own model API key, so artifacts go to your provider, not to us. Decisions may quote short excerpts. How DevOS handles data

Your architecture has reasons.
Let your agent read them.

Start with one repository.

Get started