Fix: Main Session Shows a Large Warning Triangle After Reading a Big File (OpenClaw 2026.3.12)

A community report indicates that OpenClaw 2026.3.12 can get the main:main session stuck in an unusable state: the chat pane is replaced by a large warning triangle, and normal input/replies don’t work.

Source

• Issue report: openclaw/openclaw#45442
• Session storage + paths: Session Management docs
• Session listing CLI: openclaw sessions

This isn’t a release note. It’s a recovery playbook: what to try first, how to safely “unstick” the main session, and how to prevent it.

What the symptom looks like

From the report:

• Trigger: asking a small local model (example: qwen3:8b via Ollama) to open/read a large-ish text file (~12KB+).
• After that, only main:main breaks: the chat area becomes a warning triangle.
• Other sessions still work.
• Restarting the gateway didn’t help.
• Deleting some session files by hand didn’t help.

Fast recovery checklist (least risky → most invasive)

1) Confirm it’s not just a UI cache glitch

If you’re using the Web Control UI:

• Hard refresh the page.
• Try a different browser profile.
• Clear site data for the gateway origin (cookies/localStorage) and reload.

If the warning triangle persists only for the same session, continue.

2) Try a session reset from within chat (if you can still type)

If the input box still accepts text, send one of the reset triggers:

• /reset
• /new

This forces a new session id for the same session key, which can sidestep a corrupted context.

If you cannot type at all in main:main, you’ll need to repair the stored session artifacts from disk (next section).

Preserve three evidence items before resetting anything

The giant warning triangle often pushes operators to delete main:main session artifacts too quickly. That makes the incident harder to review. Before you reset anything, preserve three evidence items:

1. A screenshot or exact visible error text, so you can distinguish this from a normal frontend rendering glitch.
2. The backup path for the related session file, transcript, or local state directory.
3. The last model, message entrypoint, and user input that triggered the freeze, so the next operator can tell whether the likely cause was small-model output, corrupted session artifacts, or an entrypoint issue.

This does not fix the issue by itself, but it keeps the recovery reversible, handoff-ready, and reviewable.

Repair main:main by resetting its on-disk session artifacts (safe, reversible)

OpenClaw stores session state on the gateway host.

According to the docs, the typical paths are:

• Store file (per agent): ~/.openclaw/agents/<agentId>/sessions/sessions.json
• Transcripts: ~/.openclaw/agents/<agentId>/sessions/<SessionId>.jsonl

For the default agent, that’s usually:

• ~/.openclaw/agents/main/sessions/sessions.json
• ~/.openclaw/agents/main/sessions/<SessionId>.jsonl

The key for the main direct session is commonly agent:main:main.

Step A — identify the session key and confirm it exists

Run:

openclaw sessions --all-agents

You’re looking for a session that corresponds to main:main (often shown as agent:main:main).

Step B — back up, then “move aside” the transcript and store entry

Goal: make OpenClaw recreate the session cleanly on next message, without permanent deletion.

1. Stop the gateway (so it doesn’t rewrite while you edit):

openclaw gateway stop

2. Create a backup directory:

mkdir -p ~/.openclaw/agents/main/sessions/_rescue

3. Back up the store file:

cp ~/.openclaw/agents/main/sessions/sessions.json \
  ~/.openclaw/agents/main/sessions/_rescue/sessions.json.$(date +%Y%m%d-%H%M%S)

4. Locate the transcript file for the broken session.

If you can find the sessionId in sessions.json, move that JSONL aside:

mv ~/.openclaw/agents/main/sessions/<SessionId>.jsonl \
  ~/.openclaw/agents/main/sessions/_rescue/

If you can’t easily locate it, you can still recover by temporarily moving the whole store file (OpenClaw will recreate entries):

mv ~/.openclaw/agents/main/sessions/sessions.json \
  ~/.openclaw/agents/main/sessions/_rescue/sessions.json.moved.$(date +%Y%m%d-%H%M%S)

5. Start the gateway again:

openclaw gateway start

6. Open the UI and send a new message.

Expected result: the broken main:main session is rebuilt (new session id), and the UI becomes usable again.

Why this works

The docs state that the store is a map from sessionKey -> { sessionId, ... } and that deleting entries is safe; they are recreated on demand.

If a single transcript/message causes a rendering failure, forcing OpenClaw to mint a fresh session id + transcript file can break the “bad state” loop.

Preventing reoccurrence (when using small local models)

This failure mode was triggered by asking a small model to ingest too much raw text.

Practical mitigations:

1. Chunk large files: ask the agent to read the file in sections and summarize each part.
2. Prefer a “triage prompt”:
   • “List headings / functions / TODOs first”
   • “Summarize, then ask me which section to deep dive”
3. If you run local models, set conservative limits (context window, file tool limits) so one accidental request can’t poison a primary session.

Who this guide is most useful for

This recovery playbook is especially useful for three groups:

• People using small local models for daily driver sessions, where one oversized file read can poison the most important chat.
• Operators who keep critical context in main:main, and need the least destructive path before deleting anything.
• Teams supporting non-technical users, because a large warning triangle often gets reported as "OpenClaw is broken" instead of a session-specific failure.

A 60-second triage: refresh the page or rescue the session?

If you arrived here from search, the hard part is usually not the command sequence. It is deciding which layer is actually broken. Use this quick split before touching session files:

1. One browser is broken, but an incognito window works: clear site data first. Do not touch gateway files yet.
2. Only main:main is broken while other sessions work: treat it as a single-session persisted-state problem. Back up first, then move the matching transcript aside.
3. Every session is broken and gateway logs are noisy too: stop focusing only on main:main; switch to gateway, model service, or Web UI outage triage.
4. The failure appeared right after a small model read a large file: record that read action in your evidence bundle, because it is likely the trigger that poisoned the primary session.

This split prevents unnecessary deletion. Only the second case should normally enter the session rescue path in this guide.

Common recovery questions

When should you stop trying UI-only fixes and move to session-file recovery

If hard refresh, another browser profile, and /reset or /new still leave only main:main broken, the problem is likely in the persisted session state rather than the browser layer.

Is it safer to move the JSONL transcript or the whole sessions.json first

If you can identify the exact sessionId, moving only that JSONL file is the narrower fix. If not, moving sessions.json is still a reversible recovery move, because OpenClaw recreates entries on demand.

When should you stop treating the warning triangle as a UI bug and assume the persisted session state is poisoned

If hard refreshes, a clean browser profile, and chat-level resets like /reset or /new still leave only main:main broken while other sessions remain healthy, the safer conclusion is that the persisted session artifacts are now the problem. At that point repeating UI-only steps usually just burns time, while the higher-yield move is to back up the session store and force OpenClaw to rebuild the broken session id.

Which operators should document a rescue runbook for main:main before letting local models read large files in production

Teams that keep operational context, live incidents, or shared assistant history in main:main should formalize this recovery path first. If local models are allowed to read raw logs, transcripts, or large config files, one poisoned primary session can block the highest-value workflow. A short rescue runbook reduces panic, avoids manual deletions, and makes support faster for non-technical users.

What should you collect before handing this off upstream or to another operator

Before you escalate, collect the smallest evidence pack that lets the next person distinguish "browser glitch" from "persisted session state is poisoned":

• the exact prompt or file-read action that happened immediately before the warning triangle appeared
• the session ID or agent:main:main mapping shown by openclaw sessions --all-agents
• a screenshot of the warning triangle state plus the timestamp it appeared
• gateway log lines around the failed read or the first reload after the UI became unusable

That handoff bundle makes it much easier to decide whether the next step is a safe local reset, a transcript backup, or an upstream bug report with enough detail to reproduce.

If you want a lightweight preflight before letting a small model read a big file, what should be on it

A useful preflight can stay very short:

• confirm whether the model really needs the full raw file, or can start with headings, structure, and suspicious sections only
• confirm whether the test is happening in main:main, or whether a disposable session would be safer
• confirm that the rescue path, backup directory, and session storage location are already documented before anyone experiments

That checklist sounds basic, but it meaningfully lowers the chance of turning a one-off file read into a blocked primary session.

Triage checklist before resetting the session

Before you force-reset the main session, capture enough evidence to avoid losing the real failure mode:

1. Note whether the warning triangle appears before or after the first assistant token streams.
2. Check if the same account can open a fresh non-main session without the large warning UI.
3. Save the visible error text, browser console errors, and the latest gateway/session log timestamp.
4. Only then try a soft reload, because a reset that clears the symptom can also erase the clue that identifies the broken state transition.

This gives operators a fast way to separate a cosmetic UI regression from a session-state failure that can make chat unusable.

Search intent add-on: what people usually mean when they search this problem

In practice, people rarely search for the exact phrase "large warning triangle in main:main" first. They usually come in through symptoms and urgency, for example:

• "OpenClaw main session broken after reading file"
• "main:main unusable after local model opened big text file"
• "OpenClaw warning triangle chat cannot type"
• "how to reset corrupted OpenClaw main session"

That means this guide works best when it clearly answers three search intents fast:

1. Can I recover without deleting everything? Yes, usually by backing up and moving aside the broken session artifacts first.
2. Is this the entire app failing? Usually no, if other sessions still work and only main:main is broken.
3. What is the safest next step for operators? Stop repeating UI-only retries, back up the persisted session state, then force a clean rebuild.

Adding those distinctions matters because operators under pressure tend to overreact, delete too much, or misclassify the issue as a full-site outage.

Verify four things after recovery

If you already cleared the warning triangle, do not treat that as the end of the incident. Verify these four things first:

1. The broken main:main session can really type and send again.
2. Other sessions still work, so the fix did not spread the damage.
3. The moved session artifacts were backed up, not permanently deleted.
4. Reopening the same main session path does not immediately bring the warning triangle back.

The point is not “it looks fine now.” The point is that the main session is restored, the side paths still work, and the evidence is still available.

If you still can’t recover

If the above steps don’t fix it:

• Capture gateway logs around the time the warning triangle appears.
• Share the reproduction steps + your storage layout in the upstream issue.

Upstream tracking: openclaw/openclaw#45442

FAQ: how to triage the warning triangle fastest

If only main:main is broken while other sessions still work, what should you assume first

The highest-yield starting assumption is that this is a single-session persisted-state failure, not a full OpenClaw outage.

That matters because it changes the response path immediately. If every other session is still healthy, spending more time on broad gateway or browser panic moves usually delays recovery. A narrower session-artifact reset is the more efficient operator move.

What is the lowest-risk recovery order if you want to avoid losing history unnecessarily

The safer order is: back up first, move aside the narrowest broken artifact second, rebuild wider state only if needed.

In practice that means you should not start by deleting everything under the session store. First identify the sessionId behind agent:main:main and move only that JSONL transcript if possible. If exact identification is slow or blocked, only then fall back to temporarily moving sessions.json so OpenClaw can recreate the mapping.

When should this be treated as an operational incident instead of just one user's local annoyance

If main:main carries shared working context, active incident notes, or the highest-value operator history, this should be treated as an incident even if the rest of the product is technically still up.

At that point the risk is not just one broken chat pane. The real risk is losing continuity in the team's main operating lane. The correct priority becomes preserving evidence, protecting other healthy sessions, and restoring the primary workflow with the least destructive reset path.

Convert warning-triangle traffic into the right next step

If this page is the first landing page from search, use the symptom to choose the next action instead of resetting everything immediately:

1. One session is unusable, other sessions still work: preserve the broken session folder, start a clean replacement session, and compare model/runtime differences before deleting anything.
2. Every session now shows the warning triangle: stop treating it as a single-session corruption case and inspect gateway health, provider auth, and recent model overrides first.
3. The warning started after switching to a small local model: reduce context, retry with a stronger fallback model, and only then decide whether the transcript artifact is damaged.

This keeps high-intent visitors on the safest recovery path: identify scope first, then reset only the smallest piece necessary.

Search intent reinforcement: turn this into a five-minute recovery card

If more than one teammate can hit this failure mode, do not leave the answer buried in a long incident note. Turn the recovery path into a short internal card:

• Line one defines scope: only main:main is broken, or every session is broken.
• Line two defines the smallest safe move: back up first, then move only the identified broken transcript if possible.
• Line three defines escalation: if a fresh session also breaks, gateway logs are noisy, or provider auth fails at the same time, stop treating this as single-session corruption.
• Line four defines the forbidden move: do not clear the session store without a backup, a sessionId, a screenshot, and a log timestamp.

This matches the intent behind most warning-triangle searches: operators do not need a theory essay first; they need to know whether it is safe to touch session files now.

Incident commander handoff: explain the state in three sentences

When the main session is already stuck, the fastest way to lose time is making every operator rediscover the state. Compress the handoff into three sentences:

1. Scope: only main:main is affected, or every session / Web UI path is affected.
2. Evidence preserved: screenshot, sessionId, last triggering action, and gateway log timestamp are already captured or not.
3. Next move: keep trying UI-only recovery, move one JSONL transcript aside, or escalate to gateway / provider / auth troubleshooting.

This gives the next responder an immediate operating picture. It also moves warning-triangle search visitors from panic to a handoff-ready incident flow instead of repeating destructive cleanup attempts.

If it comes back after recovery, capture these five recurrence signals

When the warning triangle disappears and then returns, the first fix probably cleared the symptom without finding the trigger. Capture five signals before the next reset:

1. Is it still limited to main:main? If the scope expands, stop treating it as one broken session and inspect gateway / provider paths.
2. Does it recur after reading a large file? Save file size, model, context window, and the last tool input together.
3. Does it only recur under one runtime? Record model/provider/runtime overrides so a model limit is not misread as a UI failure.
4. Does reload work briefly and then break again? That points toward persisted state failing on reload, not just a browser-cache issue.
5. Do fresh sessions start failing too? Once a new session reproduces it, stop moving old transcripts and inspect global config plus gateway logs.

These signals turn “it broke again” into a recurrence pattern that can guide local mitigation or a stronger upstream issue report.

After the review, run these four drills to avoid deleting the main session by mistake

After the warning-triangle incident is recovered, the highest-value follow-up is not another screenshot. It is a low-risk drill. Run these four checks so the next broken main session is handled by procedure instead of guesswork:

1. Locate the artifact: map the UI agent/session name back to the real transcript or session artifact path, so the responder knows which file is in scope.
2. Practice the backup: copy the target artifact into a temporary folder and write down the restore command before anything is moved.
3. Practice the fallback lane: open a clean replacement session and confirm the team can still send a minimum viable reply while main is down.
4. Practice rollback: restore the backup artifact and restart the relevant process, proving that a mistaken move can be undone.

These drills turn this page from emergency recovery into an operating runbook, especially for self-hosted teams that treat main:main as a long-lived workbench.

If search traffic arrives after a model change, separate UI failure from context pressure

A warning triangle that appears right after a model or runtime change is easy to misread as a broken web UI. For operator traffic, the faster split is whether the UI is failing by itself or whether the selected model hit a context boundary first.

Before moving session files, check these branches:

1. The triangle appeared after opening a large file: record the file size, model, runtime, and last tool call before resetting anything.
2. A stronger fallback model can continue the same turn: treat the incident as model/context pressure and reduce the next reproduction, rather than blaming the whole UI.
3. The same page fails before any model response starts: preserve browser console output and gateway logs, because the issue may be session-state loading rather than generation.
4. New sessions are healthy: keep the fix scoped to the damaged main session and avoid clearing unrelated session history.

This gives search visitors a safer first filter: prove the context/model trigger before touching persisted session artifacts.

Add a no-destruction preflight before touching session storage

Before you move a transcript, rename a session folder, or clear browser state, run a short no-destruction preflight. The goal is to prove whether the warning triangle is attached to one persisted session, one browser profile, or the whole OpenClaw runtime.

1. Open one fresh temporary session and send a tiny prompt. If it works, the failure is probably scoped to the old main:main state.
2. Capture the first gateway error after reload instead of the last noisy stack trace. The first error usually shows whether the failure came from session loading, provider auth, or response rendering.
3. Write down the exact last risky action: large file read, model switch, browser refresh, manual transcript edit, or gateway restart.
4. Only then choose the recovery lane: UI cache cleanup, single-transcript quarantine, or full gateway/provider investigation.

This preflight is intentionally boring. It prevents the most expensive mistake in warning-triangle incidents: deleting the only useful evidence before you know whether the problem is local, session-scoped, or global.

Turn warning-triangle traffic into UI severity routing

If you arrived because a huge warning triangle covers the main session, makes chat unusable, or blocks the message area, triage the blast radius before filing a generic screenshot. First check whether the input box still sends, whether history still scrolls, whether refresh reproduces it, and whether the same account is blocked in other channels.

The minimal evidence packet should include a full-page screenshot, browser width, current channel, the last agent output before the warning, and the refresh result. Escalate it as a P0/P1 main-session UI bug only when the warning triangle consistently blocks reading or input. If it is isolated to one rendered message, debug content rendering or markdown fallback first.

Related reading

• Troubleshooting OpenClaw agents
• OpenClaw complete installation guide
• OpenClaw ACP One‑Shot Run Looks Empty in sessions_history (Even When .jsonl Transcript Exists)
• Session Force Resets Immediately After User Questions in Kimi Claw Channel