# Bug: command\_status permanently returns "RUNNING" for completed background commands

**URL:** <https://discuss.ai.google.dev/t/bug-command-status-permanently-returns-running-for-completed-background-commands/128671>\
**Category:** Google Antigravity\
**Tags:** bug\
**Created:** [March 4, 2026, 8:50pm UTC](https://discuss.ai.google.dev/t/bug-command-status-permanently-returns-running-for-completed-background-commands/128671 "2026-03-04T20:50:19Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![Llorens\_Santacreu](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/llorens_santacreu/32/23542_2.png) [@Llorens\_Santacreu](https://discuss.ai.google.dev/u/Llorens_Santacreu)\
**Post date:** [March 4, 2026, 8:50pm UTC](https://discuss.ai.google.dev/t/bug-command-status-permanently-returns-running-for-completed-background-commands/128671/1 "2026-03-04T20:50:19Z")

</div>

## Bug: Background commands get permanently stuck as “RUNNING”

**Environment:** Antigravity on Arch Linux, long coding sessions (multi-hour)

### What happens

1. The agent runs a command via `run_command` with `WaitMsBeforeAsync` shorter than the command duration
2. The command goes to background and returns a CommandId
3. The command finishes — I can see the output and my shell prompt in the terminal UI
4. The agent calls `command_status` → gets `Status: RUNNING`, `No output`
5. The agent polls again and again — always `RUNNING`, `No output`
6. The agent is stuck in a loop. I have to cancel it manually

The command has finished. I can see it. But the agent never detects it.

### Minimal reproduction

### Key details

- **Intermittent:** Same command pattern sometimes works, sometimes doesn’t. No predictable trigger.
- **Permanent:** Once lost, the reference never recovers. Polling indefinitely won’t help.
- **read\_terminal also fails:** Returns empty output for the same CommandId.
- **Ghost terminals accumulate:** The “Running terminal commands” metadata shows commands as “running for 6+ hours” that finished long ago. They never get cleaned up.

### Impact

The agent freezes for 5-10+ minutes polling a dead reference, multiple times per session. The user has to cancel, copy-paste the terminal output, and tell the agent to continue. This breaks the workflow and happens several times during a normal coding session.

### Expected behavior

`command_status` should detect when the background process has exited and return `DONE` with the output, regardless of whether partial output was captured during the initial `WaitMsBeforeAsync` window. Ghost terminals should be cleaned up when their process is no longer alive.

---

<div class="post-metadata">

**Author:** ![Merlin\_Merlin](https://d1dlmcr85iqnpo.cloudfront.net/user_avatar/discuss.ai.google.dev/merlin_merlin/32/142153_2.png) [@Merlin\_Merlin](https://discuss.ai.google.dev/u/Merlin_Merlin)\
**Post date:** [August 18, 2026, 3:33pm UTC](https://discuss.ai.google.dev/t/bug-command-status-permanently-returns-running-for-completed-background-commands/128671/2 "2026-08-18T15:33:31Z")

</div>

I’ve managed to solve the problem. In my case it was a log tool searching for results of commands going through whole system log, which made cores run at close to 100% for a long time searching for log from the commands ran in sandbox by Antigravity. I hope it helps 🙂

> [@\[macOS\] Antigravity Sandbox spawns runaway \`log show\` EXEBOX processes at 100% CPU — workaround found](https://discuss.ai.google.dev/t/macos-antigravity-sandbox-spawns-runaway-log-show-exebox-processes-at-100-cpu-workaround-found/178834):
>
> Hi, I believe I found the cause, or at least a very strong contributing factor, behind a macOS Antigravity/Antigravity IDE sandbox issue where terminal commands remain RUNNING / show “Empty log” even after the underlying command has completed. I have also submitted this through Antigravity’s built-in Feedback mechanism. Symptom With Sandbox enabled, terminal executions cause Antigravity to launch processes like: /usr/bin/log show --style json --predicate (senderImagePath CONTAINS “Sandbox” …