Investigate why a service is getting killed

Run a read-only SSH check to find the cause of a process death and rank fixes by risk.

Done with CodexClaude Code· Intermediate

What they did
A developer had Claude Code shutting down almost immediately on an Ubuntu server, so they asked Codex CLI from their Mac to inspect the machine remotely. They supplied the SSH address and the symptom, and Codex requested permission before connecting, then reviewed memory, active processes, limits, and kernel messages through journalctl.
How it went
Codex traced the failure to the OOM killer, which had terminated claude on a 1.9 GB droplet that had no swap configured. It also noted MySQL using about 786 MB and returned a set of repair options ordered by risk, without making any changes.
Tips
When a box is unstable, start with a read-only investigation so you can confirm the cause before touching settings. In this case, the first suggestion was a 2 GB swap file, and the author later said that would have been cheaper than resizing the droplet.

Try it yourself with Claude Code

I have a server at [user@host] and [service name] keeps getting killed. Connect over SSH and diagnose the cause without changing the machine. Check kernel messages, memory use, swap status, process activity, and service logs; if you need to run anything that could alter the system, stop and ask for my approval first with the exact command. Finish with your diagnosis and a list of possible fixes, sorted from lowest risk to highest risk.

Fill in the [brackets]. Agents can make mistakes, so review anything before it is sent, paid or deleted.

Read the original on flaviocopes.com ↗

Get 3 agent uses like this every morning

With the day's top AI news. Free, and one click to unsubscribe.