> ## Documentation Index
> Fetch the complete documentation index at: https://docs.open4rena.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Code intelligence

> The code index, language servers, and architecture diagrams the model uses to understand a codebase, plus Workspace Radar and Project Scout.

Besides reading and searching files, the model has tools that answer
structural questions about your code: where a function is called, what a
file imports, where a type is defined. These come from a code index that o4
builds for your project and from language servers you have installed. You
don't run these tools yourself. Ask a question and the model picks the right
one:

```text theme={null}
Who calls parse_config, and which files would a change to it affect?
```

## The code index

When a session starts, o4 builds or updates a code index in the background.
The index lives at `.o4/index/codebase.db` in your project. The first build
covers every supported file, and later sessions only reindex files that
changed.

The index covers these languages:

| Language | File extensions |
| - | - |
| Rust | `.rs` |
| TypeScript and JavaScript | `.ts`, `.tsx`, `.js`, `.jsx` |
| Python | `.py` |
| Go | `.go` |

o4 skips files your `.gitignore` excludes and files larger than 1 MB.

The index records symbols (functions, methods, structs, classes, traits),
the calls between them, and each file's imports. When the index exists, o4
also adds a short summary of the project's structure to the model's context
at the start of a session.

### Querying the index

The model queries the index with the `codebase_query` tool. It runs without
asking for approval. If the first background build isn't finished yet, the
query waits up to 60 seconds for it, then runs anyway.

| Operation | What it finds |
| - | - |
| `find_symbol` | Symbols whose names match, across the whole codebase. |
| `symbols_in` | Every symbol defined in a file. |
| `callers_of` | Every call site of a function or method. |
| `callees_of` | The functions called from inside a function. |
| `imports_in` | The imports in a file. |
| `imported_by` | Files that import a given module. |
| `depends_on` | Files that import from a given file. |
| `dependents_of` | What a given file imports. |
| `types_in` | Type definitions in a file. |
| `find_type` | Type definitions whose names match. |
| `members_of` | The members of a type. |
| `changed_together` | Files that often change in the same git commits as a given file. |

`changed_together` reads your git history instead of the index, so it works
for any file in a git repository.

## Architecture diagrams

The `show_architecture` tool draws a diagram of the codebase from the index as
a Mermaid flowchart. It runs without asking for approval. Ask for one when you
want an overview:

```text theme={null}
Show me the module dependency diagram for this repo.
```

| Scope | What it shows |
| - | - |
| `modules` | Dependencies between modules, grouped by crate or top-level directory. |
| `files` | The file tree as a graph. |
| `calls` | The call tree of one function. |

## Language servers

The `lsp` tool gives the model answers from a language server, which
understands types and scopes that the index doesn't. It supports:

* `goToDefinition`, `goToImplementation`, and `findReferences`
* `hover`, for type and documentation information
* `documentSymbol` and `workspaceSymbol`
* `prepareCallHierarchy`, `incomingCalls`, and `outgoingCalls`

o4 starts a language server the first time the model asks about a file of
that type, and keeps it running for the session. The `lsp` tool asks for
approval once per session in the default approval mode. It's available in
interactive sessions, not in print mode.

With no servers configured, o4 uses these, if they're installed and on your
`PATH`:

| Server | File extensions |
| - | - |
| `rust-analyzer` | `.rs` |
| `typescript-language-server` | `.ts`, `.tsx`, `.js`, `.jsx` |
| `pyright-langserver` | `.py` |
| `gopls` | `.go` |

<Warning>
  In 0.2.74, o4 doesn't send language servers the `initialize` request that the
  protocol requires first. Standard servers such as `rust-analyzer` answer every
  request with a "not initialized" error, so the `lsp` tool returns
  `LSP error -32002` instead of a result. For definitions and callers, the model
  can use the code index above. See
  [language servers and formatters](/extend/lsp-and-formatters) for details.
</Warning>

o4 doesn't install language servers. To add or change servers, see
[language servers and formatters](/extend/lsp-and-formatters).

## Workspace Radar

Workspace Radar keeps a list of open items in your project that need
attention. In o4 0.2.74, o4 adds items in two cases, both as warnings:

* You quit a session with unresolved open threads. When you quit, o4 asks
  the model to list them as part of the session debrief (see `/debrief`).
  Each becomes an item titled `Open thread: ...`.
* A background task fails. The item is titled `Task failed: ...` with the
  task's description, and its details hold the error. If the same task fails
  again, o4 updates the existing item and counts the failures, as in
  `Task failed ×3: ...`.

The list is stored in `.o4/radar.db` in your project. When you start a session
and there are open items, the chat shows a one-line digest, for example
`Workspace Radar: 2 warnings active (promise:2) · 1 new · /radar`. "New" counts
items added since the previous digest.

Run `/radar` or press `Alt+T` to open the **Radar** pane. `Alt+T` is the
remappable `toggle_radar_pane` action. Items are grouped by severity, so in
0.2.74 they all appear under `Warnings`. The selected item's details show
below the list.

| Key | Action |
| - | - |
| `↑`/`↓` or `k`/`j` | Move between items. |
| `Enter` | Show the item's full details. `Esc` goes back to the list. |
| `f` | Fill the prompt with a request to fix the item, including its details and a reminder to verify the fix with `test_run`. |
| `d` | Fill the prompt with the same request, asking the model to hand it to a background `General` subagent. |
| `s` | Snooze the item for 24 hours. It comes back after that. |
| `i` | Ignore the item. It doesn't come back. |
| `Esc` or `q` | Close the pane. |

`f` and `d` close the pane and only fill in the prompt, so you can edit the
request before you send it. Workspace Radar has no settings.

## Project Scout

Project Scout looks at your project and suggests built-in tools and skills to
turn off, and MCP servers to turn on or off, so the model's context holds only
what the project needs. Run:

```text theme={null}
/scout
```

`/scout --diff` opens the same pane. Scout only runs when you ask for it;
it doesn't open by itself when a session starts.

Scout looks at the top of the project: manifest files such as `Cargo.toml`,
`package.json`, or `go.mod`, folders such as `tests`, `docs`, or
`.github/workflows`, the test framework, and the git history. From these it
builds suggestions from a built-in set of rules, such as turning off
`test_run` in a project with no test folder.

The **Project Scout** pane lists each suggestion with a cost marker, its
estimated token cost per request, the tool, server, or skill it affects, and
the reason. The footer shows the total for your current setup and for the
setup with your selections applied, for example
`Current: 6076 tok/req → Projected: 6076 tok/req (−0%)` before you select
anything. Suggestions start unselected.

| Key | Action |
| - | - |
| `↑`/`↓` or `k`/`j` | Move between suggestions. |
| `Space` | Select or clear a suggestion. |
| `a` | Select all suggestions. |
| `n` | Clear all suggestions. |
| `Enter` | Apply the selected suggestions. |
| `Esc` | Cancel. |

Applying replaces the `[scout]` section of `.o4/config.toml` in your project,
and o4 says `Scout recommendations saved to .o4/config.toml; restart session
to apply tool, MCP, and skill changes`. The changes take effect in your next
session, and only in a [trusted workspace](/safety/workspace-trust), because
o4 reads a project's `.o4/config.toml` only there. Print mode (`-p`) ignores
the section.

The section looks like this. You can also write or edit it by hand:

```toml theme={null}
[scout]
disabled_tools = ["test_run"]
disabled_mcp_servers = ["browser"]
enabled_mcp_servers = ["github"]
disabled_skills = ["release-notes"]
```

| Key | What it does |
| - | - |
| `disabled_tools` | Tools to leave out of the model's tool set, by name. |
| `disabled_mcp_servers` | MCP servers to turn off in this project. |
| `enabled_mcp_servers` | MCP servers to turn on in this project. They must already be configured; Scout doesn't install servers. |
| `disabled_skills` | Skills to leave out. |
| `disabled` | Set to `true` to ignore the rest of the section. |

Scout also writes `first_run`, `profile_hash`, and `last_run`, which have no
effect in 0.2.74. See [configuration](/reference/configuration#scout) for the
full reference.

## Related pages

* [Language servers and formatters](/extend/lsp-and-formatters): configure
  the servers the `lsp` tool uses.
* [Subagents](/guides/subagents): the `Explore` agent searches the codebase
  in its own context.
* [Tools](/reference/tools): every tool the model can use.