Sessions, history, and coordinated work

Use Sessions to find running work or return to a saved conversation. Resume reopens the same provider conversation; Continue in gives a new conversation the context it needs to pick up the work.

The timeline shows activity across sessions, while the Session Log helps explain status changes and failures. For terminal controls and crash recovery, see Terminals and Recovery and troubleshooting.

Contents

• Find work in the Sessions panel
• Resume the same conversation
• Continue work in a new conversation
• Tutorial: review and handoff
• Titles, summaries, and worktree reports
• What history is retained
• Use the Session Timeline
• Read the Session Log
• Delegate work through Logonomic
• Messages between running sessions
• Advisory coordination for advanced agents

Find work in the Sessions panel

Open Sessions to see terminal views, the displayed delegated task, and remembered conversations. Choose Show to reveal an existing view, or Resume to reopen a remembered conversation. Expand a card to check its repository, launcher, account, command, status, summary, and reported worktrees.

The panel keeps its groups in this order:

Use a group's chevron to fold remembered or non-resumable entries. The panel's title shows the total entry count, and the matching count when searching, before pagination.

A disabled Resume action explains what is missing when you hover or expand the card. A stopped terminal may still offer Show because its view remains open. Show reveals that surviving terminal, including its final output. Details can be expanded separately. A session link whose terminal view is no longer open shows its retained details and explains that the terminal is not open.

A terminal surviving a crash in Soter is still running. Continue using that terminal; see the recovery chapter for handoff guidance before trying to return it to the workspace.

Read a session card

A title describes the work; the account and provider identify the conversation behind it. Two sessions can use the same repository and account for different tasks, so check the expanded details when names are similar.

Started is the provider-reported start time. Opened is the time the view opened when no reliable start time was available. A remembered age such as 12m, 3h, or 8d measures time since its last recorded update; now means less than a minute and ? means no usable time. That age does not indicate whether resume has recently been checked.

Details are selectable text. Remembered entries can include the provider session ID and resume explanation; live managed sessions can include Peer messages. Missing account or command information appears as Unknown.

Sort the list

Sort by changes order within each group:

• Oldest first or Newest first orders by session start or recorded time.
• Needs attention (newest), the initial setting, puts questions and hints first, then permission requests, ready-for-input or uncertain quiet work, and other live work. Newer entries come first at equal priority.
• Needs attention (oldest) uses the same priorities with older work first.
• LLM provider groups by provider name, with earlier work first.
• Name (repo) groups by repository name, with earlier work first.

Among ended sessions, failures precede cancelled and normally ended work. Read the status detail before acting on an attention indicator.

Search sessions and page history

Type into Search sessions to match a title, summary, repository or reported worktree path, provider/account name, or date. Search ignores case and surrounding spaces; dates can use the displayed form or yyyy-MM-dd. Press Escape in the field to clear the query and selection.

Search filters all groups, including live, interrupted and non-resumable entries. The resumable group's page controls offer 10, 20, 50, or 100 matches per page, initially 10. Logonomic remembers the page size and returns to page one when the query changes. Other groups show all their matches.

Select several entries

Click a row, Ctrl-click to toggle individual rows, or Shift-click to select a range. Selection stays within one group and, for paged history, the displayed page. Right-click selected remembered entries for Resume or Remove. Continue in works with one source session at a time.

With the list focused, Up/Down moves selection, Shift+Up/Down extends it, and Ctrl+Shift+Up/Down extends it while retaining the existing selection. Ctrl+A selects the group's displayed rows. Space selects the current row with the same Ctrl/Shift modifiers; Enter uses its Show/navigation action. Delete requests removal of remembered entries. Escape, clicking blank panel space, or hiding or collapsing the panel clears selection.

Resume the same conversation

1. Find the conversation in Resumable sessions.
2. Expand it and check the account, original directory, summary, and provider session ID if needed.
3. Choose Resume.
4. Wait for the terminal to start and for confirmation that the provider opened the requested conversation.

Resume needs the original provider conversation, a usable account/profile and worktree, and a compatible launcher. A saved entry can remain even after its provider files or account become unavailable. Read a refusal's explanation and correct that cause before retrying; Logonomic does not substitute a fresh conversation.

Check the provider capabilities and setup when a launcher opens normally but cannot resume. Session history and exact resume have different requirements: a remembered activity record alone cannot recreate the provider's conversation.

This conversation is already open and Resume is already in progress mean an existing or starting instance is using it.

Resume several conversations

Select remembered rows and choose Resume. Logonomic starts them one at a time. The status line counts resumed, queued, starting, skipped, failed, and not started entries, with the latest failure explanation.

Stop queued resumes removes pending starts. It leaves successful terminals and the one accepted start in progress alone. Removing a remembered row also removes its pending start. If an accepted start fails, the remaining queue stops. A refusal before acceptance records the failure and proceeds to the next entry. Session limits still apply; see editions.

Remove a remembered row

Select remembered entries and choose Remove, or press Delete. This removes them from the Sessions list. It does not delete provider conversations or repository files, close running terminals, or perform Close and forget.

If any remembered selection is stale or already resuming, the batch is refused and nothing is removed. Live views in a selection are kept. Read any storage error before assuming the removal was saved.

Continue work in a new conversation

Use Continue in to switch launcher, account, or provider while carrying forward context from earlier work.

1. Select one eligible running, ended, or remembered conversation.
2. Open Continue in from its context menu or terminal actions.
3. Choose a compatible Codex or Claude launcher, the continuation destinations supported by the integrations described in this guide.
4. Read the new agent's account of the earlier work and its proposed next steps.
5. Confirm or correct that understanding before authorizing it to continue.

The new session starts in the source's recorded directory. It receives a brief with the title, latest summary, known worktrees, provider conversation and state location, relevant times, and earlier continuation relationships. It can read the original transcript and project state if they are accessible; the brief itself does not contain the full transcript.

The brief tells the agent to investigate read-only and wait for your reply before changing anything. The target CLI's permission settings still govern its tools. If the earlier session is running, it stays running: both sessions can see and change the same files after authorization. Tell the new agent about changes made since the summary was written.

The menu includes launchers whose installed add-on can supply the first message. The command and settings must also meet the provider's continuation prerequisites. The source needs recorded conversation information, and a remembered source needs a usable directory. If the brief cannot be saved or the target cannot accept it, the start is refused with an explanation.

Tutorial: review and handoff

Use the uncommitted README change from the first tutorial. This example distinguishes a one-shot review task, a message to a running interactive session, and a new conversation created by Continue in.

Prepare two launchers

Keep the resumed conversation open as the caller. You also need a saved Claude launcher for the distinct Read-only review task and a compatible Codex or Claude launcher for continuation; see Sessions and tasks. Open the review launcher's configuration and enable Available for read-only review for its identified account. This opt-in is off by default. Accounts and native CLI permissions still apply.

Delegate a read-only review

Ask the caller:

Use Logonomic delegation to submit a read-only review to [review launcher name], in this repository. Inspect the uncommitted README.md change against HEAD. Do not modify files or commit. Return the exact change, whether it matches our request, and any remaining concern. Use the distinct read-only review purpose; if that launcher cannot provide it, tell me rather than submitting an implementation task.

Replace the bracketed name with your saved launcher's name. Writing “review” in an implementation prompt does not make that task read-only.

Open Session Timeline and select the child task linked to the caller. Check Purpose and Working directory. Use Events while it runs and Result for its final answer. Wait for a confirmed final outcome and read the result; then compare it with the file's Show Diff. Closing the task view only changes the view. A one-shot task has no conversation composer.

Send a message to a running peer

Start a second interactive launcher in logonomic-example and leave it running. Give it a narrow instruction:

Wait for a Logonomic peer message about the README review. Do not change files. When asked, read your inbox and report what the message says.

Ask the caller to list live managed sessions, identify this peer by its repository and launcher, and send:

The README review is complete. The change remains uncommitted. Please read your inbox and leave the file unchanged.

The agent integration can use the session messaging commands. Use the live managed session ID, not a provider conversation ID. Open the peer's details in Sessions and expand Peer messages to inspect the stored message. Ask the peer to read its inbox and send a reply confirming receipt. Inspect that reply before relying on the confirmation. A successful send alone confirms storage, not that the recipient has read or acted on the message.

Continue in Codex or Claude

Select the original caller in Sessions, open Continue in, and choose the compatible Codex or Claude launcher. The new conversation starts in the source's recorded directory with a context brief. The original session remains running.

Wait for the new agent to explain the earlier work. Reply:

Read README.md and its diff without changing anything. Confirm the edit is still uncommitted and explain what the earlier review concluded. Tell me if the original conversation or review result is unavailable to you.

Inspect Sessions and the timeline to find the new conversation and its relationship to the source. Compare its account of the work with the actual diff and retained review result. The continuation brief is not the full transcript, and access to earlier provider files can vary.

Once its understanding is correct, choose your next task and authorize that work explicitly. End or close the waiting peer if you no longer need it. Avoid assigning concurrent edits to the same file in the original and continued conversations.

Titles, summaries, and worktree reports

Managed agents can suggest a title once the task is clear. Your own title takes precedence.

The Summary records the objective, progress, important decisions, and remaining work. Agents are asked to reconsider it after important changes and periodically during work, but the displayed text depends on the agent sending an update. Check its timestamp before relying on it. Updated means new text was saved; reviewed means the agent confirmed the existing text.

The launch worktree is recorded when session attribution is available. Agents can report other worktrees they change, including work delegated elsewhere. A done marker means the agent reported finishing there; it does not merge, clean, delete, or lock the worktree. These reports help the next session find its context.

Agents can use the title, summary, and worktree commands to maintain this information.

What history is retained

Recording and Git attribution

Control local resume recording and Git session trailers in Settings.

Remembering and forgetting

An LLM terminal offers Close and remember and Close and forget. Remembering requires an identified, resumable provider conversation; unavailable choices explain what is missing. A resumable conversation is also remembered when its terminal exits, crashes, or is cancelled.

Close and forget excludes the session from Logonomic's history and timeline, including attribution that arrives late. The provider's own conversation files remain. For the effect of closing on running work, see Terminals.

Session history, terminal scrollback, provider transcripts, timeline activity, token usage, and diagnostic logs are separate records. Retaining one does not guarantee that the others, or a usable resume point, still exist.

Count-based history budget

Stopped-session history defaults to 1,000 sessions, without an age cutoff. To change it, edit orchestration/settings.ini beside the profile's orchestration_manifest.json:

[orchestration]
history_session_limit=1000

The file is created on the first retention check. Use a non-negative integer; changes apply at startup or a subsequent session update. An invalid value or failed write preserves history and reports a diagnostic.

Logonomic removes the oldest eligible stopped sessions and associated task records. Running terminals, sessions whose closure is still being confirmed, and context/results needed by live tasks or their callers are protected, so retained history can exceed the limit. Setting 0 keeps only protected context.

Eviction removes Logonomic's history relationships. Provider conversations, repository contents, token-usage records, and the timeline's independently retained execution history remain.

Interrupted history and unavailable resume

Interrupted history survives later starts even when an exact conversation resume is unavailable. Session details, continuation context and messages remain under the same stopped-session budget as other retained history.

A missing worktree, inaccessible drive or share, unavailable provider or session-attribution storage failure can prevent Resume without removing the entry. Restore access or resolve storage errors before trying Resume. Resume checks the recorded conversation and worktree identity before starting.

Use the Session Timeline

Open Session Timeline to see when work ran. Time runs horizontally; rows group root sessions, delegated tasks, and provider-reported subagents. Native subagents can appear beneath a parent without having their own terminal tab.

Drag to pan and use the mouse wheel over the time area to zoom around the pointer. Over the labels, the wheel scrolls rows; Shift+wheel scrolls rows from the time area too. You can also use the right-hand scrollbar and drag the label divider to adjust its width.

Click a span to select its session, Ctrl-click to add or remove selections, and double-click a row to reveal an available terminal or structured result. Click blank space or press Escape to clear selection. Use a family's chevron to collapse child lanes; that choice survives restart.

After navigating into the past, Follow current time returns to the present. The Later activity strip jumps to the next activity beyond the visible range; hover for its titles and time.

Selecting a structured task updates its open viewer. Clearing selection leaves the result visible. A historic terminal row cannot restore an ended process; use Resume in Sessions to reopen its conversation.

Each root shows up to six detailed native-agent lanes, with additional agents represented by a count. The detail depends on provider reports. Timeline history retains up to 4,096 execution events and 8 MiB, independently of the stopped-session budget. Native child-agent detail is a live observation, not a complete durable transcript across restarts.

Read the Session Log

Show Session Log through the workspace panel controls; it is hidden in the initial layout. It lists recent activity and diagnostics, newest first, with time, session, and relevant details such as command, directory, reason, or exit code.

Rows such as Working, Ready for input, Attention requested, and Last turn failed describe observed state. Hover for the fuller explanation, including whether it was confirmed, inferred, or unavailable. Click an actionable event to reveal its available terminal.

The panel displays up to 80 rows from a 512-event buffer and combines repeated output-activity entries per session. This explains why its event and displayed-row counts can differ. Use the terminal or provider history for the full conversation.

Delegate work through Logonomic

Use Logonomic delegation when you want a task performed by a different saved launcher, account, or provider. Ask the current agent explicitly, naming the launcher and describing the task, working directory, expected result, and permitted changes. Ordinary requests for subagents normally use the current provider's own agent tools.

The target must be a saved launcher that supports the requested task. Its model, account, authentication, and native tool permissions apply. See provider setup; agents can use the command reference.

What happens when a task starts

Logonomic creates a child session linked to the caller and runs the task in the specified existing non-bare Git checkout. It produces activity events and a final result.

An Implementation task uses the launcher's tool permissions. A Read-only review uses a distinct provider capability and appears only for targets supporting it. Writing “review” in an implementation prompt does not change its permissions.

Tasks are one-shot: their view has no conversation composer. Ask the calling agent to submit another task for follow-up work.

Inspect Events and Result

Open a delegated session from the timeline. Its view shows Provider, Status, Purpose, and Working directory. Use Events for recent searchable activity and Result for the final Markdown answer. A result opens automatically unless you deliberately selected Events.

Select result text to copy it through the context menu. With the result focused, Ctrl++/Ctrl+= zooms in, Ctrl+- zooms out, Ctrl+0 restores 100%, and Ctrl+wheel also zooms. The 50%–300% setting is shared across result views and remembered.

Cancel task requests termination while the task is active. Closing the tab or switching sessions only changes the view. Cancellation may take time to confirm, and it does not undo edits or other actions already performed.

Interpret task outcomes

Pending, resolving, or starting means preparation is underway. Working/running means the provider is executing. Finished/completed means it returned a complete result without a reported execution error; review the answer before relying on it.

For Failed, read the accompanying error. For Cancelled, check for edits already made. Interrupted means execution could not continue; retained history is not a running process. If cancellation cannot be confirmed, inspect the task before assuming it stopped.

Events are a bounded recent view. Retained results can be reopened from history after earlier live events are no longer available. Status, result, and cancel commands belong to the original live caller; knowing its task ID does not give a later session control of the task.

Delegation limits and timeout settings

Structured tasks run as noninteractive processes without terminal surfaces. Their four-task limit is separate from Logonomic Free's four interactive terminal slots. A plain shell or coding-agent terminal occupies a terminal slot; a structured one-shot implementation or review task occupies structured task capacity. Launching an interactive continuation uses a terminal slot.

Execution timeouts begin when the task runs; startup has separate deadlines. A timeout is a failed/interrupted operation.

To change a default, edit structured_session_settings.json in Logonomic's persistent configuration directory. Each purpose has its own record; this example allows 15-minute reviews and 30-minute implementations:

{
  "structured_review": {
    "present": true,
    "version": 1,
    "timeout_ms": 900000
  },
  "structured_implementation": {
    "present": true,
    "version": 1,
    "timeout_ms": 1800000
  }
}

Use a positive integer up to 2,147,483,647 milliseconds for timeout_ms. Setting present to false refuses new submissions for that purpose unless they include timeout_ms. A malformed or unsupported record affects only its purpose; invalid JSON makes both defaults unavailable until fixed. A missing file or purpose record initializes that purpose's built-in default. Errors are reported rather than silently using another timeout. A valid explicit timeout_ms overrides its purpose's default and can be supplied even when that default is unavailable.

Changing a setting affects new tasks. Use the per-task timeout_ms override for a different deadline; see Structured delegation tools.

Messages between running sessions

Live managed sessions can exchange short messages, including across different runs. An unread count appears on the session's icon/header and in its details. Expand Peer messages to read up to ten recent messages; the panel indicates when older ones exist.

Reading this desktop preview leaves the agent's unread state unchanged. The agent reads its inbox through the messaging commands. Its integration reports an unread count at a new turn rather than immediately inserting every message into its conversation.

A successful send means the message was stored, not that the recipient acted on it. Peer messages do not authorize changes beyond your instructions.

The recipient can explicitly acknowledge receipt with message acknowledge MESSAGE_ID. This is separate from reading, agreement, and completing the requested work. The desktop view shows Awaiting, Acknowledged, or Ended per recipient. At supported provider checkpoints, the agent is also told how many retained messages still await its acknowledgement; this does not interrupt an ongoing action.

Agents can use message inbox --pending to find these messages even after reading them, and message status or message wait to inspect receipts. Repeating an acknowledgement retains its first receipt time. Ended unacknowledged recipients and expired messages are not acknowledgement success. See Acknowledge and inspect receipt for the bounded wait. Acknowledgement does not pin a message: read messages follow the retention limits below and can be removed before acknowledgement.

Messages allow 16 KiB each. A live recipient can hold 64 unread messages and 1 MiB unread content. Across recipients, the limits are 1,024 unread deliveries and 2 MiB unread content within a 4 MiB retained store. Reading inboxes can release capacity. Older read/sent and stopped-session history is removed first; live unread messages are protected.

Messages and read state follow session history. Removing one participant's history leaves another participant's retained copy intact.

Advisory coordination for advanced agents

Optional coordination tools let agents report intended work over a Git checkout directory and see overlaps with other sessions. These WorkIntent declarations help agents negotiate concurrent work; they neither lock files nor reserve worktrees. Linked worktrees are shown as related checkouts.

Declarations expire with their owning session and are separate from the saved Worktrees reports in session details. Ordinary terminal work needs no claim/release procedure. Integration authors can find the tools in the advanced coordination reference.