---
title: "Cortex inbox behavior"
canonical: https://workspace.socra.com/docs/cortex/concepts/inbox
---

# Cortex inbox behavior

Your Cortex inbox shows unblocked work assigned or routed to you, including work already in progress. Cortex calculates a separate inbox for each Account member or Account Agent.

## When an Issue appears

An Issue appears in your inbox when all of these conditions are true:

- Its status is `open` or `in_progress`.
- Every Issue it depends on has a terminal status of `done` or `canceled`.
- You are the Issue's responsible operator.

Cortex selects one responsible operator in this order:

1. The Issue's assignee.
2. The owning Module's default assignee, when the Issue is unassigned.
3. The Module owner, when neither assignee is set.

An Issue appears in only one inbox. An explicit Issue assignee takes precedence over Module routing. Reassigning the Issue moves it to the new operator when the other conditions remain true.

A Module owner can route its unassigned work to a default operator:

```bash
socra cortex module update MODULE_NAME --default-assignee ACCOUNT_MEMBER
```

`ACCOUNT_MEMBER` can be a directory handle or an Account user ID. Remove the default route to send unassigned work back to the Module owner:

```bash
socra cortex module update MODULE_NAME --remove-default-assignee
```

## Work that stays out of the inbox

Closed Issues do not appear. This applies to both `done` and `canceled` Issues.

A blocked Issue stays out until every declared dependency closes. A canceled dependency releases downstream work in the same way as a completed dependency.

Work assigned to another operator appears only in that operator's inbox. Module ownership does not provide a second inbox copy.

Use the full Issue list when you need to inspect blocked, closed, or differently routed work:

```bash
socra cortex issue list
```

## Read your current inbox

List your released work, ordered by Issue creation time with the newest first:

```bash
socra cortex inbox
```

The default page contains up to 20 Issues. Request up to 100:

```bash
socra cortex inbox --limit 100
```

When more results exist, the CLI prints the `--after` value for the next page. Pass that Issue ID back unchanged:

```bash
socra cortex inbox --after ISSUE_ID
```

The inbox is tied to the Account and principal in your current CLI session. Review [Access and permissions](/docs/cortex/administration/access-and-permissions) if the result belongs to a different Account than you expected.

## Watch inbox changes

Stream inbox lifecycle events until you stop the command:

```bash
socra cortex inbox watch
```

The command writes one JSON event per line. It reports these changes:

- `socra.cortex.inbox-item.v1.created` means an Issue entered your inbox.
- `socra.cortex.inbox-item.v1.updated` means Cortex refreshed an Issue that remained in your inbox.
- `socra.cortex.inbox-item.v1.deleted` means an Issue left your inbox or moved to another operator.

A fresh watch starts at the current event boundary. It reports later inbox membership changes and does not replay the Issues already in your inbox. The stream does not include comments or every Issue timeline event. Run `socra cortex inbox` whenever you need the current state.

The CLI reconnects after a temporary disconnect and resumes from the last event received by that running process. Stop the stream with `Ctrl+C`.

## Use the inbox from another interface

The MCP server exposes the current inbox through `issue_inbox`. The Cortex API exposes the same paged view at `POST /v1/issues/inbox`.

The watch stream is a WebSocket at `wss://cortex.socra.cloud/v1/inbox/watch`. Authenticate with the same Bearer token used for the API. The server first sends a `ready` frame with an opaque cursor. Each later `event` frame contains another cursor. Persist the newest cursor and add it as the `after` query parameter when your client reconnects.

Review the [Cortex MCP reference](/docs/cortex/reference/mcp) or [Cortex API reference](/docs/cortex/reference/api) before using those interfaces directly.