Internal agent sessions close immediately

[dhaern]

What happened?

Magic Context internal agent sessions such as historian, historian-editor, dreamer, and sidekick are closed/deleted almost immediately after they run.

In practice, when one of these agents starts, its session/pane may appear only for a moment and then disappear before the user can inspect what happened. This makes it hard to debug failed or partial historian/dreamer runs, inspect the produced output, or understand why an internal agent did not behave as expected.

This is especially visible now that internal agents are surfaced like normal OpenCode subagent sessions while they are running: the session briefly opens, Magic Context reads the output, and then the child session is deleted right away.

Expected behavior

Internal Magic Context agent sessions should remain inspectable after they complete, at least long enough for the user to review the transcript/output when needed.

The important part is not to keep them running forever, but to avoid deleting the child session immediately after Magic Context has read its result. These agents produce useful diagnostic context, and immediate deletion removes the ability to inspect that context from the UI/session history.

Actual behavior

The internal agent session is created, prompted, Magic Context reads the result, and then the child session is deleted immediately. Visually this looks like the historian/dreamer/sidekick pane flashes open and closes almost instantly.

Why this seems to happen

From the observed behavior, Magic Context appears to treat these child sessions as temporary implementation details: create child session -> run prompt -> read output -> delete/cleanup in the same lifecycle.

That makes sense for hidden background bookkeeping, but it becomes problematic when these child sessions are visible/inspectable as agent sessions. The lifecycle is too aggressive for debugging and transparency: by the time the user notices the agent ran, the session may already be gone.

Affected agents

• historian
• historian-editor
• dreamer
• sidekick

There may be other internal Magic Context agents using the same lifecycle.

Impact

• Hard to inspect historian/dreamer output after a run.
• Hard to debug failed or unexpectedly short internal-agent executions.
• The UI appears to flicker because the child session is removed immediately.
• Users lose useful diagnostic history for Magic Context automation.

Environment

• Magic Context: 0.20.0
• OpenCode: 1.15.x

Notes

I am not suggesting a specific code-level fix here. The main issue is the Magic Context lifecycle for internal child agent sessions: they should not be deleted immediately after their output is read if they are intended to be inspectable/debuggable like other agent sessions.

[dhaern]

Adding a bit more context here:

The issue seems to be about the lifecycle/inspectability of Magic Context internal agent runs, not necessarily about the agent failing.

From the visible behavior, Magic Context appears to run internal agents as short-lived child sessions: create the child session, prompt the agent, read/consume the output, then clean up the child session immediately afterwards.

With recent OpenCode versions, those internal child sessions are surfaced more like regular agent/subagent sessions while they run. That makes the lifecycle visible to the user: the session or pane briefly appears, Magic Context consumes the output, and then it disappears almost immediately.

So the fast closing does not necessarily mean the historian/dreamer/sidekick run failed. It can simply be the child session being deleted right after Magic Context has consumed its output.

The practical problem is debugging and transparency. If an internal agent result is unexpected, too short, invalid, or failed, the user cannot easily inspect the child session transcript afterwards because the session has already been removed. Keeping those internal agent runs inspectable after completion, or otherwise preserving enough of their transcript/result for review, would make this much easier to diagnose.

[Milk0217]

I am encountering the same issue with a specific downstream effect that I think is worth documenting separately:

Observed behavior (restart loop)

After a Dreamer run completes, the Dreamer subagent session closes/disappears immediately (as described in the original report). The specific downstream consequence I experience is a restart loop:

1. Dreamer run starts -> completes successfully (all tasks: consolidate, verify, archive-stale, improve)
2. Dreamer child session is closed/deleted immediately after magic-context consumes its output
3. Upon starting a new OpenCode session, the Dreamer internal state appears to have lost its completion tracking
4. The Dreamer schedules and starts a new dream run from scratch
5. This new dream run also closes immediately after completion
6. -> Every session restart triggers a fresh dream run -> infinite loop

Evidence from my logs

From magic-context.log dated 2026-05-16, I can see repeated Dreamer initialization cycles:

[2026-05-16T17:46:23.393Z] [dreamer] registered project E:\... (dreaming=true; total=1)
[2026-05-16T17:46:23.393Z] [dreamer] started independent schedule timer (every 15m)
[2026-05-16T17:46:23.393Z] [dreamer] timer tick (startup) - projects=1
[2026-05-16T17:48:51.479Z] [dreamer] registered project E:\... (dreaming=true; total=1)  // <- restart
[2026-05-16T17:48:51.479Z] [dreamer] started independent schedule timer (every 15m)
[2026-05-16T17:50:31.288Z] [dreamer] registered project E:\... (dreaming=true; total=1)  // <- restart again
...
[2026-05-16T18:03:15.061Z] [dreamer] dequeued project ..., starting dream run
[2026-05-16T18:03:15.070Z] [dreamer] last dream at: 1778772302253 (project=...)
[2026-05-16T18:03:15.074Z] [dreamer] starting task: consolidate
[2026-05-16T18:05:52.189Z] [dreamer] task consolidate: completed in 157.1s

Each OpenCode session restart produces a new [dreamer] registered project + timer tick (startup) entry. The schedule window is set to 02:00-06:00 but the Dreamer still dequeues and starts a run at 18:03 (6PM) outside that window - which suggests the startup tick may bypass schedule gating.

Schedule configuration

My magic-context.jsonc uses the default schedule (no explicit override):

{
  "dreamer": {
    "enabled": true
  }
}

Hypothesis

The root cause chain seems to be:

1. Child session deleted immediately after Dreamer consumes its output (original issue Internal agent sessions close immediately #80)
2. Dreamer run completion state ("last dream at" timestamp, run results) is either not durably persisted or is reset on session restart
3. -> Next session sees stale/no completion state -> starts new Dreamer run
4. -> New run also has its session deleted -> loop

The schedule window check also appears to not gate startup-initiated dream runs, which amplifies the loop frequency.

Environment

• Magic Context CLI: 0.20.0
• Magic Context OpenCode plugin: 0.20.0
• OpenCode: 1.15.3
• OS: Windows 10.0.19044
• Config: ~/.config/opencode/magic-context.jsonc (dreamer enabled, default schedule 02:00-06:00)

[dhaern]

Additional observation after checking the local session/plugin state:

This does not look like a model failure in the latest runs. Magic Context does not record a historian failure (historian_failure_count = 0, no historian_last_error, no compartment_in_progress left behind).

The visible issue is still the child-session lifecycle:

• Magic Context creates an internal child session such as magic-context-compressor.
• The session becomes busy and a UI/multiplexer integration can attach a pane to it.
• Shortly after, the child session disappears from the active session list / is reported as idle/deleted.
• The pane manager then closes the pane as missing, idle, or deleted.
• In some cases a late busy event can arrive after deletion, causing a brief respawn/flicker attempt.

So the important part is not necessarily that historian failed. The problem is that these internal agent sessions are too short-lived / immediately deleted, which makes them impossible to inspect reliably and causes pane flicker in integrations that visualize child sessions.

A more inspectable lifecycle would help: either keep these internal sessions available after completion, or expose a clear marker that they are internal/non-visual ephemeral jobs so integrations can avoid opening panes for them.