DEV Community: Sidhant Panda

Claude might be saturating your machine

Sidhant Panda — Thu, 16 Jul 2026 17:53:53 +0000

My laptop was sitting idle with the fan at full tilt. Nothing was running that I knew of. The culprit turned out to be ten orphaned busy-loops left behind by a Claude Code session two days earlier.

Just fix it for me

If your fan is roaring right now and you would rather not read the rest, paste this into a Claude Code session:

My machine seems idle but the fan is at full speed. Check the load average against my core count, then list the top CPU consumers with their PPID, elapsed time, and full argument list. I am looking for orphaned processes: anything reparented to PID 1 that has been burning CPU for hours or days, especially shells and interpreters where the process name alone tells you nothing. Show me what you find and what each one actually is before killing anything, and let me confirm the list first.

The "show me before killing" part is the important bit, and it is why the prompt is written that way rather than as "find and kill whatever is using CPU." A long-running process pinned to PID 1 is a strong hint that something was abandoned, but it is not proof. Daemons legitimately live there, and your own nohup'd job or a detached build will look identical from a distance. Read the argument list before you agree to anything. In my case the arguments made it obvious in about two seconds.

Finding it

Start with the load average. This is a 10-core machine:

$ uptime
19:39  up 6 days,  6:14, 10 users, load averages: 122.91 167.84 162.08

Load 122 on 10 cores is not idle. Next, the top CPU consumers:

$ ps -Ao pcpu,pid,ppid,user,comm -r | head -12
 %CPU   PID  PPID USER   COMM
139.8  8320     1 user   /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
 60.9 94281     1 user   /bin/zsh
 59.4 94279     1 user   /bin/zsh
 59.4 94288     1 user   /bin/zsh
 59.1 94287     1 user   /bin/zsh
 57.9 94285     1 user   /bin/zsh
 57.6 94284     1 user   /bin/zsh
 57.6 94286     1 user   /bin/zsh
 57.3 94283     1 user   /bin/zsh
 55.9 94282     1 user   /bin/zsh
 51.1 94280     1 user   /bin/zsh

Ten zsh processes at roughly 60% each, and every one has PPID 1. That is the tell: their parent died and launchd adopted them. comm only gives you the binary name, so pull the full argument list to see what they actually are:

$ ps -o pid,lstart,etime,pcpu,args -p 94279,94280,94281

Note the comma-separated list. Passing -p alongside -A silently gets you every process on the box instead.

The arguments explained everything:

/bin/zsh -c source ~/.claude/shell-snapshots/snapshot-zsh-XXXX.sh 2>/dev/null || true && eval '
SP=/private/tmp/claude-501/<project>/<session-id>/scratchpad
# saturate all cores, then run the suite under contention
NCPU=$(sysctl -n hw.ncpu)
for i in $(seq 1 $NCPU); do (while :; do :; done) & done
LOADPIDS=$(jobs -p)
pnpm test:integration > "$SP/load.log" 2>&1
kill $LOADPIDS 2>/dev/null
...'

Elapsed time was 01-22:41:17. Just under two days of while :; do :; done on every core.

A previous session had deliberately pegged all ten cores to run an integration suite under CPU contention, then meant to clean up after itself. The test run itself was long gone, confirmed by the absence of any vitest or pnpm process:

$ ps -Ao pid,ppid,pcpu,etime,comm | grep -Ei "[n]ode|[v]itest|[p]npm"
58938 58933   0.0    00:59 .../bin/node
88656 88648   0.0 02-00:57:58 .../bin/node

Only the spinners were left. They accounted for about 700% of the 850% total CPU in use:

$ ps -Ao pid,ppid,pcpu,comm | awk 'NR>1 && $3>20 {sum+=$3; n++} END {print "procs >20% CPU:", n, " total %CPU:", sum}'
procs >20% CPU: 12  total %CPU: 850.3

Why the cleanup failed

Two things went wrong, and either alone would have been enough.

LOADPIDS=$(jobs -p) was the first. Job control is off in a non-interactive shell, so jobs -p returned nothing and the cleanup kill had no arguments to act on. Collect $! after each background spawn instead:

LOADPIDS=""
for i in $(seq 1 $NCPU); do
  (while :; do :; done) &
  LOADPIDS="$LOADPIDS $!"
done

The second is that the parent shell died before reaching the kill line at all. A cleanup step on the happy path is not cleanup. Use a trap so it fires even on interrupt:

trap 'kill $LOADPIDS 2>/dev/null' EXIT INT TERM

Fixing it

Plain kill was enough. No -9 needed:

$ kill 94279 94280 94281 94282 94283 94284 94285 94286 94287 94288
$ ps -o pid= -p 94279,94280,94281,94282,94283,94284,94285,94286,94287,94288 | wc -l
0

Afterwards, Chrome was back on top where it belongs and nothing else broke 30%:

$ ps -Ao pcpu,pid,comm -r | head -4
 %CPU   PID  COMM
129.6  8320  /Applications/Google Chrome.app/Contents/MacOS/Google Chrome
 43.2 58249  .../Google Chrome Helper (Renderer)
 27.5 69725  .../UsageTrackingAgent

The load average still read 74 at that point, which is expected. It is a decaying rolling average and lags reality by design. The 1-minute figure had already dropped from 122 to 74 and kept falling; the 15-minute figure was still carrying the previous quarter-hour of saturation. Judge the fix by the process list, not the load average. The fan takes another minute or two beyond the CPU drop while the heat already in the chassis dissipates.

Checking your own machine

uptime                              # load average well above your core count?
sysctl -n hw.ncpu                   # what your core count actually is
ps -Ao pcpu,pid,ppid,user,comm -r | head -15

Look for processes eating CPU with PPID 1 and a long etime. Reparenting to launchd plus an elapsed time measured in days means nobody is supervising it and nobody is going to clean it up. Shells and interpreters are worth a closer look, since comm shows you /bin/zsh or node and tells you nothing about what is inside. Get the arguments:

ps -o pid,ppid,lstart,etime,pcpu,args -p <pid>

On macOS, Activity Monitor sorted by CPU shows the same thing, but the process name column has the same problem: ten identical zsh rows and no hint of what they are running.

Takeaway

Agents run real commands, including ones that deliberately consume resources, and a crashed or cancelled session does not necessarily take its children with it. If you let an agent spawn background work, it is worth knowing how to spot the leftovers. ps -Ao pcpu,pid,ppid,user,comm -r | head costs nothing and would have caught this two days earlier.

Node.js logger for Discord

Sidhant Panda — Tue, 09 Jun 2020 18:07:32 +0000

I wrote a small library to send Node.js application logs to Discord in a structured format.

Github Project - https://github.com/sidhantpanda/node-discord-logger

Features:

6 levels of logging
Send complete error stack to Discord
Send JSON objects which will be pretty-printed in Discord
Configure meta data such as machine hostname, process id to be sent with every request

Some example messages.

Error Message
Warning Message
Debug Message
Info Message
Verbose Message
Silly Message

A Dockerized Nodejs Express Boilerplate with TypeScript

Sidhant Panda — Thu, 26 Sep 2019 19:49:49 +0000

Github Project: https://github.com/sidhantpanda/docker-express-typescript-boilerplate

Getting started with TypeScript for your next backend project? Or just want to play around with a TypeScript based Express server? This project’s for you!

Microsoft already has a starter repo. Why this?

There is Microsoft’s starter repo but it requires you to install a bunch of other stuff like MongoDB yourself. The Microsoft repo is a good reference repository but lacks a lot of stuff when building production applications.

How to get started?

Simple, just run:

$ bash <(curl -s https://raw.githubusercontent.com/sidhantpanda/public/master/scripts/generate-express-ts-app.sh)

Or, if you don’t trust the shell script, clone the repo:

$ git clone git@github.com:sidhantpanda/docker-express-typescript-boilerplate.git your-app-name

Features

You can spin up Mongo containers and run your Node project with nodemon with a single command, and spin them down when you are done. Just run the following command and see it happening:

$ npm run dev

Running the above commands results in

🌏API Server running at http://localhost:3000
⚙️Swagger UI at http://localhost:3000/dev/api-docs
🛢️MongoDB running at mongodb://localhost:27017

Pressing Ctrl + c will stop the server and remove all mongo containers. All the data in Mongo is persisted between the runs at data/dev/mongo .

This project also contains instructions to dockerize your application from the get go, so you get to learn Docker along with it, or experienced developers can directly start configuring the Dockerfile or docker-compose.yml files.
A custom middleware for easier async/await for your request handlers. This allows you to write less verbose and eliminate having to write try-catch blocks in your request handlers every time you want to write an async method. Just throw any error and the handler will catch it and pass it on to the Express error handler.
Sample mongoose model written in TypeScript. Lets you kick-start data modelling.
Comes with a sample Open API 3.0 spec file so you can get started with API documentation directly.
All configuration done through .env file.
ESLint + Prettier — Linting and formatting from the start
Winston as the default logger to generate debug and error log files during application lifetime.
Pre-configured Travis CI for that automation goodness.

A Colorful Logger for the Browser

Sidhant Panda — Tue, 24 Sep 2019 15:23:00 +0000

Introducing a colorful logger built for easing front-end development — logt

Features

Small library size - Only ~1.3KB gzipped!
Colorful labels to help distinguish logs by importance.
Log levels to hide less important log messages.
Show hidden messages programmatically to print logs hidden due log level.
Built with TypeScript for detailed type info and that sweet sweet autocomplete.

Installation

$ npm i logt -S

Usage

You can use this logger for your frontend projects. You can choose as an ES6 module or directly include the script in HTML.

As an ES6 module

import LogT from "logt";

const LOG_TAG = "sample tag";
const logger = new LogT("error");

logger.error(LOG_TAG, new Error("example error"));

Include in HTML

<script src="https://cdn.jsdelivr.net/gh/sidhantpanda/logt/dist/logt.min.js"></script>
<script>
var LOG_TAG = 'sample tag';
var logger = createLogger('error');

logger.error(LOG_TAG, new Error('example error'));
</script>

Peek into hidden logs

This feature allows to quickly see hidden logs in the developer tools without having to make code changes. The logger stores all hidden messages locally.

const logger = new LogT(0); // Only error logs will printed to console
logger.warn('TAG', 'warning message'); // Will not print anything to console
logger.info('TAG', 'info message'); // Will not print anything to console
logger.debug('TAG', 'debug message'); // Will not print anything to console
logger.silly('TAG', 'silly message'); // Will not print anything to console

logger.showHidden(1); // Will print the warning message
logger.showHidden(2); // Will print the info warning message
logger.showHidden(5); // Will print the debug as well as silly message

Check out the project on Github for more details documentation!

A Discord transport for Winston Logger

Sidhant Panda — Wed, 18 Sep 2019 14:24:05 +0000

I just published an npm package to send log messages directly to your Discord channel.

Check out winston-discord-transport on Github!

It's pretty straight-forward to use if your already use winston to manage server logs.

Install the package

$ npm i winston-discord-transport

Use the transport

import winston from "winston";
import DiscordTransport from "winston-discord-transport";

const logger = winston.createLogger({
  transports: [
    new DiscordTransport({
      webhook: "https:/your/discord/webhook",
      defaultMeta: { service: "my_node_service" },
      level: "warn"
    })
  ]
});

logger.log({
  level: "error",
  message: "Error intializing service",
  error: new Error()
});

If you provide an error in the log message, the transport will send the entire error stack to Discord, so you can pin point the location of error directly from the message.

Check out the README for more information!

Self Hosted Gitlab Continuous Deployment to Netlify

Sidhant Panda — Mon, 26 Aug 2019 20:23:45 +0000

If you haven't yet checkout out Netlify, you definitely should!

While Netlify has direct integration with Github, Bitbucket and the managed Gitlab service, things get confusing if you have your own Gitlab instance. This post is to help out anyone wanting to write a Gitlab pipeline to deploy their website directly to Netlify from Gitlab's CI/CD tool.

Step 1: Get your Netlify Personal Access

Head over to User Settings > Applications > Personal Access Token and generate a new access token. You put "Gitlab CD" as the description of your token. Once generated, make sure you copy and keep the access token in a file or in an active editor window.

Step 2: Get your Netlify Site API ID

Next, go to your site's setting page in Netlify Dashboard can copy the value of API ID.

Step 3: Add the variables to your Gitlab CI/CD settings

Open the repo on your self-hosted Gitlab instance and go to Settings > CI/CD.

Add the access token from step 1 under the variable name NETLIFY_AUTH_TOKEN
Add the API ID from step 2 under the variable name NETLIFY_SITE_ID.

Step 4: Add a `.gitlab-ci.yml` file to your repo

Add the Gitlab CI file to your repo. Following is a basic template to start you off:

stages:
  - deploy

deploy:
  stage: deploy
  environment:
    name: production
    url: https://your.website.com
  only:
    - master
  script:
    - npm i
    # your build command
    - npm run build
    - npx netlify-cli deploy --site $NETLIFY_SITE_ID --auth $NETLIFY_AUTH_TOKEN --prod

Step 5: Add a file named `netlify.toml` to your repo

This file contains the directory which needs to be pushed to Netlify (the directory where your project is built). It's usually named build or dist.

[build]
  publish = "build"

That's it! Now just commit these changes and push to master and see your website get deployed on Netlify :)

DEV Community: Sidhant Panda

Claude might be saturating your machine

Just fix it for me

Finding it

Why the cleanup failed

Fixing it

Checking your own machine

Takeaway

Node.js logger for Discord

Features:

Some example messages.

A Dockerized Nodejs Express Boilerplate with TypeScript

Microsoft already has a starter repo. Why this?

How to get started?

Features

A Colorful Logger for the Browser

Features

Installation

Usage

As an ES6 module

Include in HTML

Peek into hidden logs

A Discord transport for Winston Logger

Install the package

Use the transport

Self Hosted Gitlab Continuous Deployment to Netlify

Step 1: Get your Netlify Personal Access

Step 2: Get your Netlify Site API ID

Step 3: Add the variables to your Gitlab CI/CD settings

Step 4: Add a .gitlab-ci.yml file to your repo

Step 5: Add a file named netlify.toml to your repo

Step 4: Add a `.gitlab-ci.yml` file to your repo

Step 5: Add a file named `netlify.toml` to your repo