Often times, I find that my LLM can’t properly detect that a command is done executing. The “Cancel” button remains visible as shown in the screenshot, so that means it’s probably the interface in itself, not the llm, right ?
And if I click Cancel
Boom it understands and goes on to next order of business.
This is pretty annoying because I have like 4 windows opened at the same time and I don’t wanna have to double check every so often to verify that it’s not stuck on the most mundane commands.
Been asking antigravity to diagnose this. Here are some probably useful tidbits
Investigating why Antigravity cannot detect command completion on this AWS ARM64 instance. Confirmed:
node-ptyworks correctly (detects exits), ptyHost is at~/.antigravity-server, the user CAN see terminal output but the agent’scommand_statusreturns RUNNING/no-output for all backgrounded commands.
The
.antigravity-serverExtension Host correctly detects ALL command completions — I verified this in~/.antigravity-server/data/logs/20260227T180705/remoteagent.logwhere every single command (including mine from this conversation) shows[Terminal] Command completed: ... exit code 0. The shell integration (OSC 633 sequences) is working perfectly.
The
.cursor-server(from a previous Cursor installation) has abin/multiplex-server/— a TCP socket-based proxy that spawns commands, captures output, and relays exit events back to the client. It’s the bridge between the remote terminal and the agent API.The
.antigravity-serverdoes NOT have amultiplex-servercomponent. This strongly suggests the Antigravity server is trying to use the Cursor server’s multiplex-server (or expects one that doesn’t exist), which is why background command monitoring is broken.There’s also an existing internal KI that references exactly this: “multiplexer-related command completion issues on ARM64 architectures.”
I removed .cursor-server and restart everything but it didn’t work. Now my LLM tells me
On ARM64 AWS instances, the architecture-specific build of
node-pty(located at~/.antigravity-server/bin/<VERSION>/node_modules/node-pty/build/Release/pty.node) can occasionally fail to detect or relay the exit signal. The shell integration (OSC 633 sequences,PROMPT_COMMAND) may be fine — the issue is lower-level, in the native C++ module that monitors the PTY file descriptor.
Told me to kill antigravity-server and run this
ubuntu@ip-10-0-0-69:~$ cd /home/ubuntu/.antigravity-server/bin/1.19.6-d2597a5c475647ed306b22de1e39853c7812d07d && /home/ubuntu/.antigravity-server/bin/1.19.6-d2597a5c475647ed306b22de1e39853c7812d07d/node -e "
const pty = require(‘./node_modules/node-pty’);
const p = pty.spawn(‘echo’, [‘hello’], {});
p.onExit(e => { console.log(‘EXIT OK:’, e.exitCode); process.exit(0); });
setTimeout(() => { console.log(‘FAILURE: onExit not triggered!’); process.exit(1); }, 5000);
"
EXIT OK: 0
(which it couldn’t detect the exit of !) It answered
Interesting —
EXIT OK: 0meansnode-ptyitself is fine. The native module correctly detects process exits.
But the problem persists.
language_server_linux_armThe remoteagent.log reveals the full picture:
What works: Shell integration (OSC 633), node-pty, and the PTY host all work correctly. The Extension Host does detect command completion — the log clearly shows:
[Terminal] Command completed: cd /home/ubuntu/stacking_features && uv run python -c "..." exit code 1
This was logged at 09:28:17, yet my command_status poll at 09:28:36 still returned RUNNING.
What’s broken: The language_server_linux_arm binary — the ARM64-specific Antigravity language server at:
~/.antigravity-server/bin/1.19.6-.../extensions/antigravity/bin/language_server_linux_arm
This is the component that bridges the Extension Host’s terminal events to the agent’s tool interface (the command_status/run_command tools I use). It receives the “command completed” events from the Extension Host but fails to relay them to my polling mechanism. This is why:
The terminal shows the command finished ✓
The server logs show completion detected ✓
But my command_status tool still says RUNNING ✗
This is a bug in the ARM64 build of the Antigravity language server binary, not in any system-level component you can fix on the instance. It would need to be fixed by the Antigravity team in a new release.
Workaround: You can continue having me run commands — fast ones that complete within the sync window work fine. For longer commands, you may need to cancel manually when you see them finish in the terminal, as you’ve been doing.
So, is it right ? Seems like it would be but I don’t know the first thing about this
yes this a headache for me too and i need to manually stop and prompt again continue to continue. this should be resolved fast
I deal with this on my Pixelbook, too.
Thank you for bringing this to our attention. We have escalated the issue to our internal teams for a thorough investigation.
To ensure our engineering team can investigate and resolve these issues effectively, we highly recommend filing bug reports directly through the Antigravity in-app feedback tool. You can do this by navigating to the top-right corner of the interface, clicking the Feedback icon, and selecting Report Issue.
Same issue on the latest macOS Version.
Same issue on the latest Ubuntu 24 version.