I built a daily work log for Claude Code, and it never leaves my machines

Urvin Sanghavi — Sat, 26 Sep 2026 18:02:21 +0000

I use Claude Code for most of my day, on a laptop and a desktop, with a work account and a personal one. At 6 pm I often couldn't answer two simple questions: what did I actually get done today, and how much did it use?

Token counters answer the second question. I wanted an answer to the first, so I built worklog-for-claude-code, a small open-source tool for Linux.

What it gives you

Once a day you get a simple page with:

What you worked on: a short summary for each project
Tokens used: per day, per account and per model, with a 14-day chart
Everything together: all your computers and Claude accounts in one view

After setup it runs in the background. You don't have to remember anything.

How it works

Claude Code writes a local transcript for every session. The tool reads those transcripts in two ways: through Claude Code hooks that fire when a session starts and ends, and through an hourly systemd timer that catches anything the hooks missed.

For each session it writes one small JSON record into a git repo you own. Every file path is written by exactly one device, so several machines can push to the same repo without merge conflicts. A nightly job turns the records into a Markdown report, and a local web UI shows it.

Privacy was the first requirement

Transcripts contain everything you typed, so the tool is built to keep as little as possible:

It stores your first prompts in each session, cut to 300 characters, along with token counts, file names and your own commit subjects.
It never stores file contents, Claude's replies, tool output or credentials.
Before anything is written, it removes API keys, tokens, JWTs, private keys, passwords in URLs, e-mail addresses and IP addresses.
There is no server and no telemetry. Data stays on your machine and in your private repo.
AI summaries are optional and run through your own claude -p. Turn them off to keep everything fully local.

The web UI listens on loopback only, and checks the Host and Origin headers, uses CSRF tokens and sends a strict Content-Security-Policy.

Try it in 30 seconds

This runs the UI on fake data and doesn't touch your files:

pipx run --spec worklog-for-claude-code claude-worklog demo

Then open http://localhost:8766.

To install it for real:

pipx install worklog-for-claude-code
git init ~/claude-worklog-data
claude-worklog install-service

Open http://worklog.localhost:8765, fill in the short setup form and click Install hook. For several machines, put the data folder in a private GitHub or GitLab repo.

Limitations

Linux with systemd only for now. A macOS port would need launchd units, and contributions are welcome.
Claude Code only, not claude.ai chat, because chats aren't written to local transcripts.
The transcript format is unofficial, so a Claude Code update could break parsing for a while. The parser skips lines it doesn't understand instead of crashing.
Tokens are not dollars. On Pro and Max plans usage counts against limits, so no prices are shown.

Links

It's MIT licensed and version 0.1.0. If you try it, I'd love to hear what's missing.

Automatically Deploy Your App to a VPS with GitHub Actions

Urvin Sanghavi — Fri, 11 Sep 2026 00:04:23 +0000

If your deploy process is "SSH into the server, cd to the app, git pull, restart something, hope" — this post replaces it with git push.

What you'll have by the end: every push to your main branch updates the app on your server automatically. You can also trigger a deploy by hand from the GitHub UI.

This is the simple version — it has a few seconds of downtime during the restart and it builds on the server. Post 6 in this series upgrades it to a zero-downtime setup. Start here; the simple version is enough for a long time.

What is "deploying with GitHub Actions"?

GitHub Actions is a task runner built into every GitHub repo. You describe a job in a YAML file, and GitHub runs it on a fresh virtual machine when something happens — in our case, "when code lands on main."

The job we want is tiny: connect to our server over SSH and run the same commands we'd run by hand. The value isn't magic — it's that the steps are written down, always run in the same order, and don't depend on you being awake.

Prerequisites

An app in a GitHub repo.
A VPS (any provider) you can SSH into, with your app already cloned and running once — e.g. in /srv/snip, served by nginx, run by a process manager. If you don't have that yet, set it up manually first; this post automates the update, not the first install.
A dedicated Linux user for deploys (don't use root). We'll call it deploy.

Step 1: Make an SSH key just for deploys

On your local machine, generate a key pair that only GitHub Actions will use:

ssh-keygen -t ed25519 -f ~/.ssh/snip_deploy -N "" -C "github-actions-deploy"

This creates ~/.ssh/snip_deploy (private) and ~/.ssh/snip_deploy.pub (public).

Add the public key to your server so the deploy user accepts it:

ssh-copy-id -i ~/.ssh/snip_deploy.pub deploy@YOUR_SERVER_IP
# or manually: append the .pub line to /home/deploy/.ssh/authorized_keys on the server

Test it:

ssh -i ~/.ssh/snip_deploy deploy@YOUR_SERVER_IP "echo connected"

Step 2: Give the deploy user permission to restart the app

The deploy needs to restart your app process without a password prompt. If you run the app as a systemd service (snip.service), allow exactly that one command:

# On the server, as root:
echo 'deploy ALL=(root) NOPASSWD: /usr/bin/systemctl restart snip, /usr/bin/systemctl reload nginx' \
  | sudo tee /etc/sudoers.d/snip-deploy

Adjust for your stack: if you use PM2, supervisor, Docker Compose, etc., substitute the restart command you actually run.

Step 3: Store the secrets in GitHub

In your repo: Settings → Secrets and variables → Actions → New repository secret. Add three:

Name	Value
`VPS_HOST`	your server's IP or hostname
`VPS_USER`	`deploy`
`VPS_SSH_KEY`	the entire contents of `~/.ssh/snip_deploy` (the private key, including the `BEGIN`/`END` lines)

Secrets are encrypted and never printed in logs.

Step 4: The workflow file

Create .github/workflows/deploy.yml:

name: Deploy

on:
  push:
    branches: [main]
  workflow_dispatch:        # adds a "Run workflow" button in the Actions tab

# Never run two deploys at once.
concurrency:
  group: deploy-main
  cancel-in-progress: false

jobs:
  deploy:
    name: Deploy to VPS
    runs-on: ubuntu-latest
    steps:
      - name: Deploy over SSH
        uses: appleboy/ssh-action@v1.2.2
        with:
          host: ${{ secrets.VPS_HOST }}
          username: ${{ secrets.VPS_USER }}
          key: ${{ secrets.VPS_SSH_KEY }}
          script: |
            set -euo pipefail
            cd /srv/snip

            # Get the exact code that's on origin/main.
            git fetch origin main
            git reset --hard origin/main

            # Install dependencies and build.
            # Adjust for your stack:
            npm ci
            npm run build

            # Apply database migrations.
            # Adjust for your stack:
            npm run migrate

            # Restart the app.
            sudo systemctl restart snip

Commit and push it to main.

What each part does

on.push.branches: [main] — run only when commits land on main. Pull requests don't trigger it. (Post 2 adds a test job that does run on pull requests.)
concurrency — if you push twice quickly, the second deploy waits for the first to finish instead of racing it.
git reset --hard origin/main — not git pull. This guarantees the server's code is exactly origin/main, even if something on the server got modified. Nothing should ever be edited directly on the server.
set -euo pipefail — stop on the first error instead of charging ahead. If npm run build fails, the deploy stops before the restart, and your old version keeps running.

Step 5: Watch it run

Push any commit to main, then open the repo's Actions tab. You'll see the workflow run live. Click it to see the SSH output.

To deploy without a new commit (e.g. to retry): Actions → Deploy → Run workflow.

Common gotchas

Permission denied (publickey) — the private key in VPS_SSH_KEY doesn't match the public key in authorized_keys, or you pasted only part of it. Re-copy the whole file.
could not read Username for 'https://github.com' — your server's clone uses an HTTPS remote, which can't authenticate non-interactively. Switch it to SSH with a deploy key, or make the repo public, or add a step that sets a token.
npm: command not found — the non-interactive SSH session has a minimal PATH. Use full paths, or add source ~/.profile / source ~/.nvm/nvm.sh at the top of the script.
Build gets killed on a small server — npm run build can run out of memory on a 1 GB VPS. Add swap, or build in GitHub Actions and copy the result over — that's covered in post 2 and post 6.
The site is broken for a few seconds on every deploy — expected with this approach. Post 6 fixes it.

What's next

Right now a commit that breaks the app will still deploy — the workflow doesn't know the difference between working code and broken code. Next: run your test suite in CI and only deploy if it passes.

DEV Community: Urvin Sanghavi