[BUG] language_server causes extreme disk writes when terminal commands emit frequent \r progress updates

Google Antigravity
1

Description

Antigravity’s language_server generates extremely high disk write activity while running a terminal command that frequently redraws a progress bar using carriage returns (\r).

During one download task, the process accumulated approximately 573 GB of disk writes, even though the captured task log was only about 38.9 MB and the SQLite conversation database was about 5.7 MB.

Observed write throughput peaked at approximately 477 MB/s.

Environment

  • OS: macOS

  • Application: Antigravity

  • Process:

    /Applications/Antigravity.app/Contents/Resources/bin/language_server

  • SQLite journal mode: WAL

Steps to reproduce

  1. Start a terminal task from Antigravity.
  2. Run a command that frequently redraws an in-place progress bar using \r, for example a downloader that updates after every downloaded chunk.
  3. Monitor the Antigravity language_server process in Activity Monitor.
  4. Observe its “Bytes Written” counter and disk write rate.

The command that triggered the issue in my case was:

.build/release/mlx-downloader download --all-gemma4

The exact downloader should not be important; any command producing high-frequency carriage-return progress updates may reproduce the issue.

Actual behavior

  • language_server accumulated approximately 573 GB written during a single task.

  • Short sampling showed write rates including:

    ~477 MB/s

  • Reads remained very low, around 31 MB cumulatively.

  • The task log was only approximately 38.9 MB.

  • The task log contained:

    237,806 carriage-return updates
39 newline characters

  • The conversation database was approximately:

    Main database: 5.66 MB
WAL file:      4.86 MB
SHM file:      32 KB

Investigation

The active task was stored in the SQLite steps table. WAL inspection showed the same small set of database pages being committed repeatedly:

  • The active row in steps
  • Three overflow pages belonging to that row
  • The steps.status index page
  • The steps.step_type index page

The active row’s serialized step_payload changed during progress updates, while the rest of the task metadata remained stable.

This suggests the following write-amplification path:

Frequent terminal `\r` progress update
→ task output/state is reserialized
→ active SQLite row and index pages are updated
→ WAL append/checkpoint activity
→ the same small set of pages is written repeatedly

The task log itself may also contribute to the amplification if the entire captured output buffer is rewritten or copied whenever an in-place progress update is received.

Expected behavior

High-frequency terminal progress updates should not result in hundreds of gigabytes of physical disk writes.

Ideally, Antigravity should:

  • Coalesce or throttle \r progress updates.
  • Persist terminal state at a bounded frequency, such as once every 500–1000 ms.
  • Replace the current in-place progress line instead of appending every redraw to the persisted transcript.
  • Batch SQLite updates into fewer transactions.
  • Avoid serializing and rewriting the complete task payload for every small output event.
  • Avoid unnecessary WAL checkpoints or synchronous writes during streaming output.

Impact

  • Heavy SSD write amplification and unnecessary wear
  • High disk utilization
  • Possible UI or system performance degradation
  • Large cumulative “Bytes Written” values from relatively small terminal tasks
  • Potentially affects any long-running command with animated progress output
2

Hi @san_X ,

Thank you for providing your detailed Activity Monitor metrics and WAL inspection logs.

We tested terminal commands emitting rapid `\r` progress updates on recent builds of Antigravity IDE while monitoring the `language_server` process in Activity Monitor.

The issue is no longer reproducible on our end. Disk write throughput for `language_server` during high-frequency progress output remains at normal levels without experiencing write amplification.

Recommendation:
1.Please update your IDE to the latest build:

  • Go to **Help > Check for Updates** (or re-download the latest release from the official site).

Once updated, running commands with animated or in-place progress bars will no longer generate excessive SSD disk writes.

If the issue still persists, please reach out back to us.