Skip to content
WorkspaceDocs

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 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 or Cortex API reference before using those interfaces directly.