A session does not show up, or shows the wrong state

AigoPilot reads the session files that Claude Code, Codex and Grok write on each computer. A session you expect is not in the list, or its state looks wrong, almost always for one of a few reasons. Work down the list below; the earlier ones are the most common.

1. The project is not in the list

Projects are found from the history the tools keep, so a folder where no session has ever run is not known yet. Press the + at the top of the Projects column and add the folder. Also look at the bottom of the column: a project you archived sits under Archived projects and comes back to the list when you take it out. Codex chats that belong to no project are grouped as Chats without a project.

2. The session is hidden on purpose

Sessions started by a program rather than by a person, such as a script that runs claude -p, the Agent SDK, codex exec or Codex's own reviewers, are kept out of the way. When a project has some, a tick box Show sessions started by programs appears with their number. Tick it to see them. Archived sessions are the other place a session can be: at the end of the session list, as a line such as 1 archived sessions.

3. The tool or the account is on another computer or in another folder

A session shows up on the computer where it was written. If the project sits on a Mac or a second Windows computer, the session list shows what that computer's engine reports. The tool must be installed there, and the computer must answer; see a computer says it is out of reach.

Each extra account of Claude Code, Codex or Grok keeps its sessions in a folder of its own. The studio watches the usual folder and the folders of the accounts you added under Settings, then Accounts. A session written by an account the studio does not know is not seen. Adding or forgetting an account makes the studio look again. See several accounts.

4. The session was started outside the studio

Sessions from VS Code, a terminal or the Codex desktop app are listed, and the studio can read them. A session that is open in another program has no live card of its own in the studio: for Codex, its state comes only from its session file. The studio asks before it takes one over; sessions outside the studio explains how.

5. The state looks wrong

A state is worked out from the tool's own hooks, from whether its program is still alive, and from whether its session file keeps growing. It is not read from terminal text. Where a hook is missing, a session that looks stuck is called "maybe waiting for permission" and not claimed. A state that says maybe is the studio being honest, not broken. Open the session and look at the end of the conversation to see what it is doing.

6. The file is damaged or gone

When a session file has lines that cannot be read, the session still opens, and a note says how many lines were skipped: "N lines of this file could not be read and were skipped". If the file itself is gone, the studio says so: its history can still be read, but it cannot be continued.

7. A very large history

The first look at a big history takes a while. On the developer's computer, 3,173 session files (2.6 GB) were read in 16 seconds. If you just started the studio, wait a moment, then check again.

Still missing? Tell us the tool, the computer and whether the session was started inside the studio, in the way described in reporting a problem.

Questions