Short description
TUI notification detection appears to stay connected forever, and internal historian/subagent prompts are rendered as very large visible user messages.
What happened?
I noticed two related UX/notification issues while using Magic Context with OpenCode TUI.
- TUI notification state appears to get stuck after the first poll
From the built plugin code, drainNotifications() marks the TUI as connected:
function drainNotifications() {
tuiConnected = true;
const result = queue;
queue = [];
return result;
}
function isTuiConnected() {
return tuiConnected;
}
But I could not find a path that sets tuiConnected back to false.
This means that once the TUI has polled pending-notifications once, isTuiConnected() keeps returning true even if the TUI is later closed/disconnected.
That can affect sendIgnoredMessage() behavior. When isTuiConnected() is true, Magic Context tries to send a toast and returns early. If the toast fails because the TUI is no longer actually connected, the error is swallowed and the fallback ignored:true message is not emitted.
Expected behavior:
- TUI should be considered connected only if it has polled recently.
- If toast delivery fails, Magic Context should fall back to the ignored/no-reply message path.
Suggested fix:
- Track lastDrainAt instead of a permanent boolean.
- Make isTuiConnected() return true only if the last poll was recent, e.g. within 2–3 seconds.
- If showToast() fails, continue to the fallback path instead of silently dropping the notification.
- Internal historian/subagent prompt renders as a huge visible message
When Magic Context invokes an internal historian/compartment agent, the subagent receives a very large prompt as a normal text message:
client.session.prompt({
sessionID,
body: {
agent: "historian",
parts: [{ type: "text", text: prompt }]
}
})
In one real session, the stored prompt was around 93k characters with no trailing whitespace. The historian receives the full prompt correctly, but the TUI/multiplexer renders it as a visible user message in the subagent pane. Because the prompt is huge, the message box can fill the entire pane with a large amount of blank/unused visual space, while only a small portion of the text is visible.
Expected behavior:
- The historian should still receive the full prompt.
- The UI should not render the entire internal prompt as a huge visible message.
- It should be collapsed/hidden/summarized visually, for example:
[Magic Context historian prompt hidden — 93k chars]
or shown as a compact internal task status.
Important: I do not think the prompt should be truncated before sending it to the model. The issue is display/rendering only.
Suggested fix:
- Add a UI/display-layer collapse for very large internal Magic Context prompts.
- Or mark internal historian/dreamer/sidekick prompts in a supported way so the TUI can render them compactly.
- Avoid changing the actual payload sent to the historian model.
- Minor performance/robustness concerns
These are lower priority, but related:
- The TUI polls notifications every 500ms. This is probably fine, but it could use idle backoff or a 1s interval if there is no activity.
- Sidebar snapshot refresh uses a short debounce and may be noisy during streaming-heavy sessions.
- Some per-session caches are stored in Maps and rely on session.deleted cleanup. This is probably intentional, but using an existing bounded session map would be more robust in long-running servers.
Diagnostics
I can provide doctor --issue output if needed.
Observed locally:
- Magic Context plugin version: 0.15.7
- OpenCode client: TUI
- Platform: Linux arm64
Plugin version
0.15.7
OpenCode version
1.14.33
Platform
Linux arm64
Client
OpenCode TUI (CLI)
Log output (optional)
No crash logs. This is based on observed TUI behavior and code inspection.
Short description
TUI notification detection appears to stay connected forever, and internal historian/subagent prompts are rendered as very large visible user messages.
What happened?
I noticed two related UX/notification issues while using Magic Context with OpenCode TUI.
From the built plugin code, drainNotifications() marks the TUI as connected:
function drainNotifications() {
tuiConnected = true;
const result = queue;
queue = [];
return result;
}
function isTuiConnected() {
return tuiConnected;
}
But I could not find a path that sets tuiConnected back to false.
This means that once the TUI has polled pending-notifications once, isTuiConnected() keeps returning true even if the TUI is later closed/disconnected.
That can affect sendIgnoredMessage() behavior. When isTuiConnected() is true, Magic Context tries to send a toast and returns early. If the toast fails because the TUI is no longer actually connected, the error is swallowed and the fallback ignored:true message is not emitted.
Expected behavior:
Suggested fix:
When Magic Context invokes an internal historian/compartment agent, the subagent receives a very large prompt as a normal text message:
client.session.prompt({
sessionID,
body: {
agent: "historian",
parts: [{ type: "text", text: prompt }]
}
})
In one real session, the stored prompt was around 93k characters with no trailing whitespace. The historian receives the full prompt correctly, but the TUI/multiplexer renders it as a visible user message in the subagent pane. Because the prompt is huge, the message box can fill the entire pane with a large amount of blank/unused visual space, while only a small portion of the text is visible.
Expected behavior:
[Magic Context historian prompt hidden — 93k chars]
or shown as a compact internal task status.
Important: I do not think the prompt should be truncated before sending it to the model. The issue is display/rendering only.
Suggested fix:
These are lower priority, but related:
Diagnostics
Plugin version
0.15.7
OpenCode version
1.14.33
Platform
Linux arm64
Client
OpenCode TUI (CLI)
Log output (optional)