Bug: command_status permanently returns "RUNNING" for completed background commands

Google Antigravity
1

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.

1 Like