This page is not yet translated. Showing English version.

Troubleshooting: Freezes & Slowdowns

Read the stall indicator, find out what paused the window, and work out which pane is eating the machine.

The window stopped responding

Symptoms: the interface will not repaint, clicks do nothing, and on Windows the title bar reads (Not Responding).

A watchdog thread notices when 1DevTool's main process stops responding and records how long it paused, what it was doing, and how busy the machine was.

While it is stalled, a red dot appears in the status bar beside the memory reading. That is the useful signal: the app is stalled, not dead, so stop clicking and give it a moment.

When it recovers, a short toast appears headed 1DevTool paused, with the facts underneath:

1DevTool paused 6.2 s while system CPU was 98% — top: claude, node

The toast carries an Open Resource Manager button, which is usually where you want to go next.

Afterwards, every stall from this session is listed under Recent stalls in the Resource Manager and under Settings → General → Diagnostics, in the same plain wording:

  • Main paused 3.1 s in command "git" while system CPU was 25%. — the main process was blocked running a command
  • Main paused 4.0 s in request "list-projects" while system CPU was 40%. — it was blocked in an internal request
  • Main paused 2.2 s in background poll "git-status". — a background poll ran long
  • The system starved 1DevTool for 5.5 s while system CPU was 99%. — the machine, not the app, was the problem
  • Window paused 1.8 s (renderer did not respond). — the window itself, rather than the main process

The last two are the ones worth acting on differently: if the system starved the app, the fix is on the machine — find the process in Busiest other apps or in the Other apps bucket.

Diagnostics settings

Settings → General → Diagnostics holds four controls:

  • Main-thread watchdog — the heartbeat that detects stalls. It costs one heartbeat every 250 ms. Turn it off only if asked to during support.
  • Stall threshold — pauses shorter than this are not recorded, in milliseconds.
  • Lower terminal priority under memory pressure — Windows only. When the machine is paging or RAM is above 90%, programs you started inside 1DevTool terminals drop to below-normal CPU priority so typing in another pane stays responsive; they are restored when pressure is low, and processes outside those terminals are never touched. macOS and Linux do not let an app raise a process's priority back once lowered, so there the Resource Manager's manual Lower priority covers one terminal at a time and lasts until those processes exit.
  • Send stall reports — shares anonymous stall reports (duration, activity name, CPU load — no paths or content) so pauses can be fixed. Only sent while usage analytics is on in Tracking.

The app is using too much memory

Symptoms: Activity Monitor or Task Manager shows 1DevTool near the top of the list, and you cannot tell which part of it is responsible.

Your operating system attributes every process a terminal starts to 1DevTool, because 1DevTool is what started it. Task Manager nests the shells, node and claude under our row; Activity Monitor spreads the app across "Helper (Renderer)" rows and gives you no way to map one back to a tab.

Open the Resource Manager from the memory reading in the status bar. It splits the same total into 1DevTool, the terminals you started, and other apps — three buckets that add up to what your OS reports. Expand the terminals bucket and every pane is named the way its tab is.

To get memory back now, press Improve performance in the panel's footer: it sleeps inactive browser tabs, hibernates idle agents and clears terminal buffers in one step. Nothing is closed — tabs wake on click and agents resume on a keypress. See Hibernation.

One terminal is pinning the CPU

Symptoms: the fans are loud, typing lags, and you do not know which of your panes is responsible.

The Resource Manager flags it for you. A pane that pins the CPU across two consecutive samples, or starts flooding output, gets an attention row naming the reason — 62% CPU, or 8.4 MB/s output · throttled — with Reveal to bring that exact pane forward.

Behind the row's ⋯, in the order you would usually try them:

  1. Pause output — if the reason is a flood, this stops the firehose without killing the run.
  2. Lower priority — drops that terminal's process tree below normal so the rest of the workspace stays responsive. One-way on macOS and Linux.
  3. Hibernate — stops the agent's CLI but keeps the tab and the session.
  4. Close — last resort.

A flood of output in one pane no longer freezes typing in another: that terminal's output is batched and the pane says so, while every other pane runs at full speed. Nothing is dropped — the rest arrives once the flood ends.

Terminals feel slower than they should

  • Check GPU rendering. The WebGL row in the Resource Manager's Machine section says whether rendering is on hardware. If it has fallen back, everything draws more slowly.
  • Check how many panes are visible. GPU rendering covers a set of panes at a time; panes that are off screen give their slot back, so hiding a few can help more than closing them.
  • Check scrollback. History is bounded by memory rather than line count, so a very wide pane keeps fewer rows for the same footprint. Improve performance clears buffered scrollback across your terminals.

Related