• everyone has preferred sending and receiving platforms
• if I want to get money, I end up copy/pasting my various links everywhere

I wanted a link like panozzaj.com/$ that was easy to remember so I could type it on my phone.

Ended up making a page on this blog for this. Buttons link to my preferred receiving platforms so folks can pick how they want to send money.

It also takes an optional ?amount= query parameter (in cents) and pre-fills the payment links. For example:

panozzaj.com/$?amount=1500

shows $15.00 and links directly to that platform's payment page with the amount pre-filled.

Gotchas

Shell escaping. $ triggers variable expansion in bash, so any scripts or commands that reference the file need quoting.

I host my blog in S3, so there were a couple of additional production tweaks.

Jekyll permalink needs a trailing slash. permalink: /$ generates $.html, which means S3 serves it at panozzaj.com/$.html instead of panozzaj.com/$. Using permalink: /$/ makes Jekyll generate $/index.html, which S3 serves correctly.

S3 adds a trailing slash redirect. Requesting panozzaj.com/$ returns a 302 to panozzaj.com/$/. To avoid this, after s3 sync, we copy the object to an extensionless key:

aws s3 cp "s3://${bucket}/$/index.html" "s3://${bucket}/$" \
  --content-type "text/html"

As a result, I wanted a /reload command that I could run to restart Claude and automatically continue the conversation. Also, by making it a command, Claude can actually invoke it itself when it detects a need to reload. This allows Claude to restart itself when needed without human intervention, so it can run more autonomously.

I figured this out when making (yet another) Google Drive MCP. I wanted to have Claude build it and automatically reload to test it.

Initial exploration

Since I was in Claude Code already, I worked on this with Claude. I figured we could find an approach that worked and then codify.

First attempt: Exit with a special code

Claude's initial idea was to have the skill exit Claude with some special exit code. Perhaps exit 42 to signal "please reload", and a wrapper script to listen for that code. This would work well since I already typically run Claude via short custom commands, so we could hook into that.

I asked about reasonable or semantic exit codes, and Claude suggested using 129 rather than an arbitrary code.

However, merely exiting from a Bash tool use doesn't work. Bash commands run in subprocesses, so exiting the subprocess with a special code just kills that subshell.

Second attempt: Find a built-in flag

We looked at Claude Code's docs and --help for a way to pass an exit code to /exit, but there's no /exit <code>, /reload, or /restart built-in.

Sending SIGHUP to the Claude process

Then I asked about the Bash command terminating the parent process, which would be Claude.

The key insight was that from within a bash command, $PPID would point to the Claude process. So then:

kill -HUP $PPID

sends SIGHUP (signal 1) to Claude, which causes it to exit with code 129 (128 + 1).

The Wrapper Function

The second part of this approach is to turn my short startup command into a Claude invocation that detects that special exit code and restarts.

Before I had:

alias CL="claude --dangerously-skip-permissions"

But we need to check for the special exit code and generally be a good Unix user (preserving exit codes, etc.):

function CL {
  local continue_flag=""               # Whether to continue or not
  local restart_msg=""                 # Don't send restart message the first invocation
  local rc
  while true; do                       # Loop forever
    claude \                           # Start Claude
      --dangerously-skip-permissions \ #  Don't ask for permission    >:D
      $continue_flag \                 #  Second invocation? Pass `-c` to continue last session
      "$@" \                           #  Pass along any original additional parameters
      $restart_msg                     #  On restarts, start Claude with a "restarted" message (see below)
    rc=$?                              # Store the Claude exit code
    [ $rc -eq 129 ] || return $rc      # If Claude exited with code 129, restart.
                                       # Otherwise, don't restart, and exit with the original exit code.
    echo "Reloading Claude Code..."    # Tell the human we're restarting
    sleep 0.5                          # Seems to somewhat improve restart likelihood?
    continue_flag="-c"                 # Restart the previously used session
    restart_msg="restarted"            # Send this message to Claude when the session resumes
  done
}

Sending the restart_msg message is quite helpful. Without it, Claude waits for user input after restart. So this allows it to continue working on whatever it was working on without needing user intervention. If you wanted to send a different message, I usually just hit esc to cancel the send when Claude starts up.

I have some other wrappers like:

• CLC for running with --dangerously-skip-permissions and --continue
• CLR for running with --dangerously-skip-permissions and --resume

Claude was easily able to modify those as well. Note you'll need to reload config or start a new session to pick up wrapper changes, especially if going from alias to function.

I had a little trouble getting the restart consistently working and added the short sleep, and while it might not be necessary, it seems like it improves the likelihood that the restart works.

The Skill

The /reload skill is then just a markdown file that tells Claude to run kill -HUP $PPID. Simple, but it took a few iterations to arrive at.

First versions

I had Claude write the skill based on our learnings about the $PPID.

The initial working version was something like this:

# Reload Claude Code (restart Claude)

Reload Claude Code to pick up configuration changes (MCP servers, hooks, settings).

## Steps

Send SIGHUP to the Claude process (which is $PPID from bash):

```bash
kill -HUP $PPID
```

The user will let you know when the reload is complete.

This had Claude read the instruction and then decide to run the Bash command. That works, but it meant that Claude had to decide to call the Bash tool. Occasionally it would add commentary, ask me to restart, write current status to file (it would be reloaded soon anyway), or ask for confirmation first. This makes it less likely the restart actually happens, and it also takes longer when it does work.

Final Iteration: ! Prefix in Skill / Command file

To try to get around the non-determinism, I wanted to see if there was a way to execute a command directly from the skill.

It turns out that Claude Code supports a ! prefix in skill files for immediate command execution. So then the command can run directly without the LLM processing it at all.

The final version of ~/.claude/commands/reload.md is simply:

# Reload Claude Code (restart Claude)

!`kill -HUP $PPID`

The ! makes it fire instantly: you type /reload, the signal sends, and Claude restarts. The whole thing takes about a second, and either you or Claude can initiate.

Wrap up

This exploration was fun and educational. It has been really useful in the last couple of days when adding skills and MCP servers.

Want to install it for yourself? Just point your Claude Code instance to this blog post and have it add the skill and shell wrapper!

It turns out there's been a solution this whole time: most external monitors support a protocol called DDC/CI that lets software control hardware brightness over the display cable.

MonitorControl

MonitorControl is a free, open-source Mac app that uses DDC/CI to let you control external monitor brightness. I installed it via Homebrew (brew install --cask monitorcontrol) and it immediately detected both my monitors. The difference is remarkable. Now I can change the brightness of the display that has the mouse cursor using the standard brightness controls.

Tools I still use

I still regularly Dark Reader. It is still a nice way to shift to dark color palettes. Many sites now either seem to automatically switch colors or have color scheme support, so Dark Reader is less necessary than it was in 2016.

I use a slightly different new tab extension now: Empty New Tab Page.

Tools I no longer use

In the old post I recommended f.lux for turning screen colors warmer at night. macOS now has this built in as Night Shift.

I've also think that while the blue light / melatonin mechanism is real, the practical impact from typical screen use seems smaller than the mid-2010s hype implied. Simply dimming your screens may matter more than shifting color temperature - which makes controlling monitor brightness potentially more useful than color shifting for sleep purposes.

I don't really use MuPDF any more since I rarely read PDFs at night at this point.

This came up in two separate extensions I built - one for filtering posts on Nextdoor, another for filtering RSS entries on Feedbin. After some trial and error, I found an approach that seems to work reasonably well.

The Problem

Many websites use infinite scroll. As you scroll down, they automatically fetch and append more content. This typically works by detecting when you've scrolled near the bottom of the page.

When you add client-side filtering (hiding items based on tags, keywords, etc.), you run into a problem:

1. You hide items with display: none
2. Hidden items don't take up space
3. The page becomes too short to scroll
4. The infinite scroll loader never triggers
5. No new content loads
6. User is stuck with whatever items weren't filtered out on first load

This is pronounced when there is heavy filtering.

Failed Approach

My first attempt was to programmatically scroll to the bottom after filtering:

function scrollToLoadMore() {
  const container = document.querySelector('.entries')
  const lastEntry = container.querySelector('.entry:last-child')
  lastEntry.scrollIntoView({ behavior: 'instant', block: 'end' })
}

This didn't work reliably. If most entries are hidden, there might not be enough scroll height to trigger the loader at all. Scrolling to the "bottom" just snaps back to where you were.

The Solution

The best solution I've found is to create an invisible spacer element that maintains scroll height even when most content is hidden.

Here's some sample CSS:

/* Invisible spacer to ensure infinite scroll works when entries are filtered */
.scroll-spacer {
  height: 200vh;
  visibility: hidden;
  pointer-events: none;
}

/* Hide spacer when enough content is visible */
.scroll-spacer.has-content {
  display: none;
}

The spacer is 200% of viewport height, which ensures there's always room to scroll. It's invisible (visibility: hidden) so it doesn't affect the visual layout, and has no pointer events so it doesn't interfere with clicks.

Here's the JavaScript to manage it:

class FilteredList {
  constructor() {
    this.spacer = null
    this.MIN_VISIBLE_ITEMS = 15
    this.loadMoreAttempts = 0
    this.maxLoadMoreAttempts = 10
    this.lastItemCount = 0
  }

  createSpacer() {
    if (this.spacer) return this.spacer

    this.spacer = document.createElement('div')
    this.spacer.className = 'scroll-spacer'

    const container = document.querySelector('.entries')
    if (container) {
      container.appendChild(this.spacer)
    }

    return this.spacer
  }

  applyFilters() {
    const items = document.querySelectorAll('.entry')
    let visibleCount = 0

    items.forEach((item) => {
      if (this.shouldShow(item)) {
        item.style.display = ''
        visibleCount++
      } else {
        item.style.display = 'none'
      }
    })

    this.triggerLoadMoreIfNeeded(visibleCount)
  }

  triggerLoadMoreIfNeeded(visibleCount) {
    this.createSpacer()

    // Enough visible items - hide spacer
    if (visibleCount >= this.MIN_VISIBLE_ITEMS) {
      this.spacer.classList.add('has-content')
      this.loadMoreAttempts = 0
      return
    }

    // Show spacer to maintain scroll height
    this.spacer.classList.remove('has-content')

    // Check if new items loaded since last attempt
    const totalItems = document.querySelectorAll('.entry').length
    if (totalItems === this.lastItemCount && this.loadMoreAttempts > 0) {
      // No new items - source is exhausted
      return
    }

    // Limit attempts to avoid infinite loops
    if (this.loadMoreAttempts >= this.maxLoadMoreAttempts) {
      return
    }

    this.lastItemCount = totalItems
    this.loadMoreAttempts++

    // Scroll to trigger loading, then scroll back
    setTimeout(() => {
      const container = document.querySelector('.entries').parentElement
      container.scrollTo(0, container.scrollHeight)

      setTimeout(() => {
        container.scrollTo(0, 0)
      }, 300)
    }, 200)
  }
}

Key Details

Why 200vh? It needs to be tall enough that the page is always scrollable, regardless of how many items are hidden. 200% of viewport height guarantees this.

Why visibility: hidden instead of display: none? We want the spacer to take up space (maintaining scroll height) but not be visible. display: none would defeat the purpose.

Why scroll back up? Without this, the user's view would jump around. Scrolling to bottom triggers the loader, then we immediately scroll back so the user doesn't notice.

Detecting New Items

You'll also want a MutationObserver to detect when the page loads new items:

observeNewItems() {
  const container = document.querySelector('.entries')

  const observer = new MutationObserver(mutations => {
    let hasNewItems = false

    mutations.forEach(mutation => {
      mutation.addedNodes.forEach(node => {
        if (node.matches?.('.entry')) {
          hasNewItems = true
        }
      })
    })

    if (hasNewItems) {
      // Debounce to avoid excessive reapplication
      clearTimeout(this.filterTimeout)
      this.filterTimeout = setTimeout(() => {
        this.applyFilters()
      }, 100)
    }
  })

  observer.observe(container, { childList: true, subtree: true })
}

This creates a nice cycle:

1. Apply filters → too few visible → show spacer → scroll
2. Site loads more items → MutationObserver fires
3. Apply filters again → check if enough visible now
4. Repeat until enough items or source exhausted

Conclusion

The spacer pattern has worked well across two different extensions with different sites. This pattern should work for any site with infinite scroll where you want to do client-side filtering. The main things you need to customize are the selectors and possibly the scroll container detection.

I've been using Claude Code as my primary agentic coding tool for about 6 months now, so all examples here will use that, although I'm guessing it could be used with others. Claude Code has been solid and continually improving, especially with Opus 4.5. (But I guess ask me in a few months… :D)

Tailscale

The key part of a setup like this is having some computer that has Claude Code set up, and then being able to securely connect to it.

My current overall approach is to set up a secure network through Tailscale so I can SSH to it.

I set up my main computer (currently M3 Max Macbook Pro) to run Tailscale. First, run the Tailscale daemon with $ sudo tailscaled. (This changed my computer's hostname for some reason, which was not super desirable.)

Then configure your computer to accept SSH connections from anyone in your tailnet (basically your authenticated devices):

$ tailscale set --ssh

It seems like Tailscale has two (three!) Mac interfaces:

• a native Mac app (used for connecting to the Tailscale network)
• the same, but installable through the app store
• and one that's a CLI interface.

You need the CLI version to be able to run the tailscale ssh command, and the versions seem to need to agree with one another or you get warnings and possibly issues:

Warning: client version "1.90.8-tccf4f3c7c" != tailscaled server version "1.86.4-t3149aad97-g60158502b"
The Tailscale SSH server does not run in sandboxed Tailscale GUI builds.

For overall stability, it would probably be a good idea to have the main computer be some server instead of a laptop to be able to connect when the laptop is closed or sleeping. Until I get one set up, I have been using Amphetamine to keep my Macbook Pro awake. One thing I like about Amphetamine is that it has the ability to keep the Mac awake sometimes when in clamshell mode. This is similar to the Caffeine app I previously used. I think I ran into some issue with using that on Apple silicon mac, but maybe I was looking at the wrong site.

I'm guessing that there are other similar services, but for my needs, Tailscale seems to work consistently well and has a generous free tier. This is a pretty simple use case, so might play around with it for having some file servers or media servers or other things in the future.

SSHing from your phone

First, you need to install Tailscale on your phone and connect to the tailnet.

I have an Android phone, so I'm running the Termius app on my phone for SSH. You can enter your computer's tailnet address into the client configuration so it is a one-button startup the next time.

I don't totally love the Termius app, but it's pretty decent. Small shortcomings in this context:

• keyboard shortcuts are a bit finicky and some aren't supported (shift+enter for newline, for example)
• font doesn't support certain characters like emojis, and Claude likes to use emojis
• the (beta) voice dictation integration stops after like a second of inactivity, which makes it difficult to use
• autocorrect is off by default, and turning it on generally gives better results but sometimes it garbles the text

Usually I'll issue a prompt and then want to be notified when Claude has finished/responded. To hear beep noises from your SSH session, you can type /config, then set Notifications to Terminal Bell (\a) and be sure your phone volume is up.

Session persistence with tmux

One challenge with this setup is that if you get disconnected, you lose your current session and have to get back to it. To fix this, I like to use tmux for session persistence. (This random blog post has a decent overview of how to use tmux for this purpose) I haven't really dialed in the tmux config, but with so little screen real estate, I'm mostly only running one window at a time anyway.

Sometimes the terminal will reprint your entire buffer, which is not ideal, as it is slow and you can't read the current output while it's happening. I think this is a scroll bug in Claude Code. For me it seems to happen more when in a tmux session, but maybe that's because it's a longer session?

It will disconnect when you switch from home wi-fi to cell network (or vice versa), but you can just reconnect your SSH session.

Viewing websites

When developing websites, it's useful to view the website. To do this, you can run $ tailscale serve <port> on the host machine. This will expose the service running on that port to your tailnet. Then you can connect by typing in the URL to your mobile browser. (Example: https:​//my-computer.tail123455.ts.net)

One nice thing is that this is effectively a mobile view of your site, so you can test how it works on a real device pretty easily. It's slightly slower than a normal connection, which is actually a benefit in my opinion to optimize your site. (I believe you can do this on your computer with Chrome devtools and on your phone in the same manner, but it's nice to have this option.)

Claude Code niceties

I added the following to my global CLAUDE.md file, which are good for less typing on the computer or especially on the phone:

If I type just:
  "c", I mean "continue"
  "ss", I mean "restate current state as short summary"
  "dnmac", I mean "do not make any changes"
  "UR" (sometimes "ur") -> "update requirements files accordingly"

I also made the following custom command (/phone-mode). This is a bit newer and less vetted than the other commands but it seems directionally useful.

# Phone Mode Instructions

This is a shortcut for when I'm on my phone (possibly biking) or have a bad
connection and need quick, concise information.

Attempt to make solid progress with minimal back-and-forth. You are agentic and
can make progress autonomously.

If you need more details, ask specific, targeted questions rather than
open-ended ones. Ideally I could respond with a number or minimal words.

Prefer short answers, bullet points, or numbered lists.

Ideally keep responses under ten lines.

At the beginning of each response, write `[PHONE MODE]` to indicate and
remember you're in phone mode. If I want to exit phone mode, I'll explicitly
say so.

Best kinds of tasks

I have found that something that the agent can make meaningful progress on mostly unassisted is best. So something where there is heavy lifting but there are good tests or automated ways of determining goodness. I have had some good success with:

• adding tests, especially when paired with code coverage metrics
• fixing flaky tests
• adding features, with tests

For some specific small projects:

• improving recipes in my recipes repo
• getting organized with set of Markdown files for life tasks
• fixing things on my blog

My first Gemini CLI experience: "I messed up. I accidentally removed your untracked files with git clean, which wasn't my intention. I'm truly sorry. Since they weren't in git, I can't restore them easily."

— rands (@rands@mastodon.social) View on Mastodon

I had also run into this problem while coding with AI agents. This seemed like an opportune time to write up some thoughts to hopefully save others some time and agony.

Sometimes this issue happens to me because I get too confident in the current work direction and have not committed in a while. And then one or two prompts later, I have a broken or confusing set of changes.

Or, as Rands's post mentions, sometimes the AI agent purposely or accidentally reverts some changes and can't recover them. Also, when Claude Code compacts context, it clears the terminal, so it often can't remember changes, and then we would be unlikely to recover.

Enter jj

To try to combat this problem, I've been setting up and using Jujutsu (henceforth jj) instances for the repos that I have. jj snapshots the working copy whenever you run a jj command, so you can use its history to see and restore changes that might have otherwise gotten lost. It also works fairly seamlessly with git, which basically all of my projects use at this point. It also doesn't affect other users of your projects. So in my mind there are basically no downsides to setting it up.

It's easy to set up jj alongside an existing git repo with jj git init --colocate.

Then there are a few commands that I've been using. I just set it up on my blog repo, and have the following info:

$ jj
@  lrklqzxy panozzaj@gmail.com 2025-11-22 16:06:25 b76e8471
│  (no description set)
◆  qppwxvzp panozzaj@gmail.com 2025-11-06 10:57:53 master master@origin git_head() e9476b33
│  Add site perf audit document
...

$ git log --oneline --graph --decorate | head 1
* e9476b3 (HEAD -> master, origin/master, origin/HEAD) Add site perf audit document

So you can see from the jj command output that it knows about git commit e9476b3 (jj's identifier for that commit is qppwxvzp).

One thing I almost immediately picked up on is that jj commit identifiers use characters in the range of [g-z], which is nice since git uses the hex characters ([0-9,a-f]) for its commit hashes. So this makes it easier to not mix up the two systems' unique identifiers. jj also highlights the unique starting characters in a different color, so it's easy to type out a couple of characters:

From above, jj has a working set of changes that it currently describes with lrklqzxy/b76e8471. Or, at least it did, until I just saved this draft. Now the git identifier is something else, since the hash of the underlying filesystem changed.

The uncommitted set of changes is aliased to @. It's similar to the git working directory, but each filesystem change is actually "committed" under the hood. To save the current set of changes in jj and change @s identifier, we'd use jj describe to write a commit message.

Here's where the work-saving ability comes in. With jj, we can view the last couple of repo changes:

$ jj obslog --revision @ --patch --limit 2
@  lrklqzxy panozzaj@gmail.com 2025-11-22 16:16:46 2583d144
│  (no description set)
│  -- operation 213466f024c9 snapshot working copy
│  M _drafts/using-jujutsu-jj-with-ai-coding-agents.markdown
│  Modified regular file _drafts/using-jujutsu-jj-with-ai-coding-agents.markdown:
│      ...
│    37   37: * e9476b3 (HEAD -> master, origin/master, origin/HEAD) Add site perf audit document
│    38   38: ```
│    39   39:
│    40     : So you can see from the `jj` command output that it knows about git commit `e9476b3` (`jj`'s version of this is `qppwxvzp`), and has a working set of changes that it currently describes with `b76e8471`. Or, at least it did, until I just saved this draft. Now it's something else. So that working set is nicknamed `@`, and it's a pretty useful concept.
│         40: So you can see from the `jj` command output that it knows about git commit `e9476b3` (`jj`'s version of this is `qppwxvzp`).
│         41:
│         42: One thing I almost immediately picked up on is that the `jj` commit descriptors uses characters in the range of `[g-z]`, which is nice since `git` uses the hex characters (`[0-9][a-f]`) for its commit hashes. So this means that you'll never get the two systems' identifiers mixed up. It's not visible here, but `jj` also highlights the unique starting characters in a different color, so it's easy to type out a couple of characters.
│         43:
│         44: From above, `jj` has a working set of changes that it currently describes with `lrklqzxy`/`b76e8471`. Or, at least it did, until I just saved this draft. Now the git portion of it is something else, since the hash of the underlying filesystem changed. The uncommitted set of changes is nicknamed `@`, and it's a pretty useful concept. Similar to the `git` working directory, but each filesystem change is actually "committed" under the hood.
│         45:
│         46: To see this, we can see the last few changes:
│         47:
│    41   48:
│    42   49:
│    43   50:
│      ...
○  lrklqzxy hidden panozzaj@gmail.com 2025-11-22 16:10:37 1915095f
│  (no description set)
│  -- operation 217810a349cf snapshot working copy
│  M _drafts/using-jujutsu-jj-with-ai-coding-agents.markdown
│  Modified regular file _drafts/using-jujutsu-jj-with-ai-coding-agents.markdown:
│      ...
│    37   37: * e9476b3 (HEAD -> master, origin/master, origin/HEAD) Add site perf audit document
│    38   38: ```
│    39   39:
│    40   40: So you can see from the `jj` command output that it knows about git commit `e9476b3` (`jj`'s version of this is `qppwxvzp`), and has a working set of changes that it currently describes with `b76e8471`. Or, at least it did, until I just saved this draft. Now it's something else. So that working set is nicknamed `@`, and it's a pretty useful concept.
│    41   41:
│    42   42:
│    43   43:
│      ...

So this command (jj obslog --revision @ --patch --limit 2) basically says:

• show me the operations (obslog)
• starting with revision @ (--revision @)
• show diffs (--patch)
• limit to the last two changes (--limit 2)

Finally, when you make changes to the git repo, jj is kept in sync with it.

Long-time users of git might see this as being similar to the git svn bridge for Subversion. You get the advantages of working with git, but Subversion stays the source of truth for collaboration.

Advantages of using

I started using jj before Claude Code had its checkpointing or rewind feature. I still use this regularly since:

1. If you get out of the context window, you can still see past changes (which I am not confident rewind handles correctly, and as previously mentioned, at one point my console history would clear when context was compacted)
2. It works across editors / agents, so you don't need to rely on them implementing checkpoints. Also, if I accidentally lose a file using sed or mv or something, I could likely get it back correctly.
3. You don't need to be an expert with jj to use it. If you get in trouble, your agent should know enough to use jj to get those changes back if asked, and otherwise seems to not be trained to use it, so it won't be committing there.

I don't yet fully grasp all of the underlying concepts to be able to use advanced jj correctly, but for this one case (recovering uncommitted changes that I actually wanted) it's saved me a couple of times. And it's just kind of a cool tool.

I suspect that there are things that I could do with using this to tracking incremental changes in jj and then batching those up for git commits. Almost like git add --patch and committing, or by saving semantic changes along the way. (Maybe this would be a useful place for the agent to track detailed change history?)

Making snapshots automatic

Update (2026-01-23): One thing I got wrong in my original post: jj doesn't have a background daemon watching for file changes. It snapshots the working copy when you run a jj command (like jj status, jj log, or even just jj). So if an agent makes changes and then crashes before any jj command runs, those changes won't be in the history.

To make snapshotting more automatic, I use two approaches:

1. Shell hook - Add jj status to your shell's preexec so it snapshots before each command runs:

preexec () {
  # Snapshot jj repo before command runs
  [[ -d .jj ]] && jj status >/dev/null 2>&1
}

Using preexec instead of precmd means it only runs when you actually execute a command, not on prompt redraws or empty enters. This captures the state right before a command you type might change things.

2. Claude Code hooks - Snapshot at high-risk moments (session start and before context compaction).

In ~/.claude/settings.json:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "*",
        "hooks": [{ "type": "command", "command": "[[ -d .jj ]] && jj status" }]
      }
    ],
    "PreCompact": [
      {
        "matcher": "*",
        "hooks": [{ "type": "command", "command": "[[ -d .jj ]] && jj status" }]
      }
    ]
  }
}

The shell hook captures changes after every command you or the agent runs. The Claude Code hooks specifically target the moments when context loss is most likely:

• at session start: before the agent might delete something without having read the contents (git reset, for example)
• before compaction (when the agent might forget what it had been reading).

Adding a PreToolUse hook that runs jj status before each tool call works, but it adds a bit of latency. It seems like running time jj status only takes about 0.01s, but there might be some overhead in invoking the hook itself. Maybe not an issue if you have other PreToolUse hooks, since I believe they run in parallel.

References

I think I originally got the idea of using jj for this purpose on some Hacker News comment, possibly this one:

Eh, I can see how, if you use GitButler, the porcelain is fairly irrelevant to you, but a few days ago I decided to try Jujutsu, asked Claude how I could do a few things that came up (commit, move branches, push/pull to Github). It took me ten minutes to become proficiend in Jujutsu, and now it's my VCS of choice.

I still use Lazygit for the improved diffing, but, as long as you don't mind being in detached HEAD all the time, there's really no issue with doing that. JJ interoperates fine with git, but why would I use the arcane git commands when JJ will do the same thing much more straightforwardly?

Also, the ability to jump from branch to branch with all my uncommitted files traveling with me is a godsend. Now I can breeze between feature development, bug fixing, copy changing, etc just by editing the commit I want. If I want multiple AI agents working on that stuff, I just make a worktree and get on with it.

Not to mention that I am really liking the fact that I can describe changes (basically add commit messages) before I'm done with them, so I can see them in the tree.

JJ is just all around great.

Although a newer comment also captures this idea, and is perhaps better documented (though see my update above—the "automatically captured" claim is slightly misleading):

With jj, every file change is automatically captured (no manual commits needed), and you can create lightweight "sandbox" revisions for each Claude Code task. When things go wrong, jj undo instantly reverts to any previous state. The operation log tracks everything, making it virtually impossible to lose work.

The workflow becomes: let Claude Code generate messy experimental code → use jj squash/jj split to shape clean commits afterward. You get automatic checkpointing plus powerful history manipulation in one tool.

I've been using jj with Claude Code for months and it's transformed how I work with coding agents - no fear of breaking things because everything is instantly reversible. The MCP integration seems like added complexity when jj's native capabilities already handle the core problem.

For anyone interested in the jj + agent workflow, read my post: https://slavakurilyak.com/posts/use-jujutsu-not-git

Also, I wrote about making commits while writing a very long time ago, and it would now seem fairly obviated with jj.

Benefits:

• weight loss (about 10 pounds in my case, as an already pretty lean person)
• better metabolic health
• more stable moods and energy due to less blood sugar fluctuation

The general thought that motivated me was that having basically any added refined sugar is not a positive thing, and so I wanted to limit this as much as possible. There is basically no nutritional benefit to added sugars, and it has many negative effects like metabolic dysfunctions, obesity, diabetes, inflammation, and cardiovascular disease. Since my grandfather had type 2 diabetes, this was something that I wanted to avoid.

For a while, I was pretty hardcore about this, and would try to avoid fruits and generally go low/no carb. I have softened to basically eat fruit as it's available or desired, and have been eating rice and bread fairly liberally.

My general approach now is to eliminate the obviously bad, moderate the questionable, and still enjoy treats from time to time.

Soda

First, I went for a "cut back on obviously high sugar things, then eventually eliminate more if you want". Also going for reducing daily consumption before focusing too hard on rare things like parties / holidays. We're trying to reduce the area under the curve for sugar.

So soda intake, especially daily soda intake, would be a solid first step.

Soda deconstruction

One important strategy for me was deconstructing / decoupling aspects of soda. What makes drinking Coca-Cola (for example) so desirable / addictive? This drink has the following qualities:

• hydration
• carbonation
• caffeine
• flavor
• routine / familiarity
• sweetness

So if I had a taste for a soda, I might try to figure out why I had that taste. Was I just thirsty? Start by drinking some water. Was I bored? Maybe drink a soda water. Was I low energy? Maybe drink coffee or tea or go for a walk. Like the taste: sometimes there are flavored sparkling waters or try Coke Zero.

This sometimes resulted in me literally deconstructing a drink to try reducing sugar. I'd "triple-fist" at home by having soda water, coffee, and water all next to each other. And then I could reduce how much I was consuming of the soda while getting the other desirable effects.

Not ordering it, not buying it, having substitutes

If you don't have it in your house or available, it's going to be impossible to consume it. So the easiest way to cut back is to not buy it.

You can try drinking things like soda water.

"Free poison"

One thing that tripped me up was restaurants offering a free beverage with the meal. Often this ended up being for a fountain soda machine. I thought: "well, I don't want to waste a chance to get free soda." But then I started thinking: "if they offered me free poison, would I take it?" And my answer to that was "NO!" So this was a helpful framing to avoid consuming something that wasn't in my long term health interests.

Additional tips:

• Sometimes there's a carbonated water button next to the Sprite, great choice
• Freestyle type machines typically have soda water hidden under one of the menus (look for caffeine-free section)
• Sometimes you can do something like an unsweetened tea
• Can just drink water

Sugar in coffee / tea

Consider reducing sugar in your daily coffee or tea.

You can actually add a couple of grains of salt to reduce coffee bitterness (as well as brewing at a slightly lower temperature or higher quality bean). So that's why those salted caramel drinks are popular… (but also high in sugar).

Added sugar in food

After you eliminate the big or daily sources of sugar, if you want to continue, the next thing to go after would be the smaller aspects.

This is challenging but tractable. It just takes time, diligence, and the willingness to change habits / preferences.

Almost anything in the central part of the store is going to contain added sugar. Why? Sugar is a fairly cheap preservative that also increases the palatability of food. Adding sugar to food makes it last longer on the shelves and be more likely to sell. So the food companies are incentivized to add it to make more money.

Generally avoiding grilled meat marinates with sugar since these may produce more free radicals / other things that are carcinogenic.

I'm kind of OK with eating salad dressing with marginal amounts of sugar in a tough food environment if it makes it easier to eat a lot of vegetables. But most of the time at home you'll be able to get or make a vinegar and oil mixture that contains minimal sugar.

What to watch for

Most products marketed at you contain added sugar. No one is advertising broccoli!

I look for products that have no sugar added or artificial sweeteners. I call these "no BS".

This can be quite challenging, since there are certain classes of foods that almost always contain sugar. For example, granola, cereal, bread, condiments (ketchup, BBQ sauce), and salad dressings almost always have some kind of sugar added to it.

Food label warning words:

• "low fat": typically they replace the fat with sugar
• "sugar-free": they might be using a sweetener or artificial sweetener other than sugar
• "no added sugar(s)": might have artificial sweeteners

Even (or especially) the ones marketed as being healthy, often contain a lot of added sugar. Don't be fooled by what I call "health washed" foods:

• "organic": there are organic sugars. Think of this as food source certification, not healthiness
• "all-natural": arsenic is also all natural
• "non-GMO": could very well still contain a lot of sugar

It's easier than it's ever been with online research and shopping online so you're not "that person" in the aisle reading every ingredient label. Then when you find versions you like, can stick with those. It's also easier since the FDA changed labeling requirements to have "added sugars" listed in the ingredient list. Sometimes if you

Get plain versions of things, and add your own fruit / honey to them. This works well for yogurt. Instead of 9 grams of sugar in a fruit-on-the-bottom Greek Yogurt, you can have plain full fat yogurt and add some fruit to it.

Sometimes I found "saving" my sugar intake for a higher quality dessert was a helpful frame. Why eat something junky when I could eat something that was really good?

Artificial sweeteners

I'm not sure whether artificial sweeteners are good or bad. Like – it's not sugar, but it resembles it enough that our brains (and gut bacteria?) are somewhat tricked by it. So I'm not sure what the metabolic effects of it are.

I generally don't like the taste, which makes it easier to spot these when I'm tasting them.

Don't be tricked by things that are alternate sweetener names, or the various names for artificial sweeteners. See: https://www.nytimes.com/2016/05/22/upshot/it-isnt-easy-to-figure-out-which-foods-contain-sugar.html and https://www.ncbi.nlm.nih.gov/pmc/articles/PMC4733620/

Desserts

This was probably one that impacted me less than the average person. I typically didn't eat much dessert. But here are some thoughts.

Eventually others know you to be someone who avoids sugar and will start reducing requests for desserts.

Fruit as a dessert. It's also sweet, and is a nice substitute. I like keeping some frozen fruit, which makes for a refreshing evening treat. You can also pair it with yogurt, etc.

Conclusion

Hope this helps someone trying to reduce their sugar consumption. It's definitely a journey, and takes time and effort, but I find the health benefits are worth it.

Nowadays I can typically feel it in my finger joints the next day if I've had a lot of sugar.

Let me know if anything was helpful for you!

So… I worked with Claude Code to build a new gem (PlainErrors) that is a Rack Middleware that gives streamlined error reports for LLMs.

In practice, this should let the agent do more debugging and iterating without filling up the context.

In my test with a real Rails application, PlainErrors achieves significant token reductions over both BetterErrors and the standard Rails development error page (as calculated by OpenAI's tiktoken library):

In my test with a real Rails application, PlainErrors achieves significant token reductions over both BetterErrors and the standard Rails development error page (as calculated by OpenAI's tiktoken library):

There's a little (mostly optional) configuration, and potentially some local tweaks to get your agent sending over the right headers or other info. (And you can also direct the agent to the gem README to install or to direct it using the query params if that's easier than digging through Claude Code's config files.)

As seems to be typical recently, I basically wrote no code for this, was just guiding the LLM and having it test it in an application that I was using. And cleaning up some documentation that was a bit overly verbose.

Open to any feedback if you use this on your application, think it's cool, or have issues or missing features!

On Father's Day weekend 2020, I tweaked my back again. This was a true Father's Day weekend. My wife was working so I watched the kids the whole weekend. I was fairly deconditioned due to skipping the gym to try to avoid getting the then-novel Covid-19. Biking was sketchy for my back since the initial injury, but that weekend I took the kids around town in a bike trailer. The weight of the kids and their stuff, combined with the fact that I was minimally exercising at the time, was too much for my back to handle. I felt it tighten up, and then kept pushing. By the time we made it home, I knew I was in trouble.

Stress may play a role in pain (see On Pain and Hope), and 2020 was a stressful time for me personally (two young children, helping run a startup that just had its sales pipeline dry up and a cofounder leave), and the world (U.S. election, pandemic, etc.)

My back wasn't quite as bad off as the first time, but with the pain that I had, most days I was hardly getting out of the house. By December of that year, after starting to see the physical therapist again, I was feeling marginally better, and I decided to get a step tracker to try to walk more consistently to avoid future injury.

Now that I've kept it up for several years and feeling better than ever, I wanted to write up some thoughts and tips. If you're looking to do something like this, I hope that this article gets you off to a good start.

First watch

My first fitness watch was the Garmin Vivofit 4. Here's my Amazon review of it

The reason I got this watch was the best-in-class battery life (1 year or more) since I disliked taking past watches off to charge them. This one could stay on my wrist for basically a year.

Surprisingly, the best feature for me was the watch's step goal streak counter. Streaks greatly motivate me. Every day I hit the step goal, it would cheerily chirp about it and show the streak counter advancing by one. Every five days in a row would result in a special animation. Small things, but they kept me going.

At first the watch set an automatically calculated step goal. This was motivating since I started at a low baseline. However, it was calibrated to increase when I hit the goal, and decrease when I missed it. This ended up being hard to reason about and resulted in needing to do more steps every day that I hit the goal, which was not very motivating. ("My reward for hitting my goal today is to make tomorrow even harder?") So I took a look at my recent steps achieved and set an achievable goal of (I think) 5,000 steps.

For the last few years my step goal has been 6000 steps. I have hit a few streaks of 250 consecutive days, and likely hit the step goal 360 days out of the year for a minimum of 2 million steps per year.

Set a floor, not a ceiling

I thought about increasing the step goal further, but instead decided to try to consistently hit the goal instead. I treated the step goal as a step minimum, not a stretch goal. Or, to put it another way, I set a floor, not a ceiling.

If you're interested in doing something like this, my key piece of advice is to start and stay lower than you think you need to.

Going for a high daily goal commits you to a lot each day. It makes it a lot harder to stick with the habit. Sure, I could do the vaunted 10,000 daily step day on occasion, but the effort (and time!) needed to achieve this day after day is very high. Time constraint was one of the things I learned while doing the fitness challenge.

When people pick exercise goals, they often imagine working out under ideal conditions. I would recommend imagining how many steps you'll want to get when:

• it's going to rain all day
• it's 100 degrees outside and 90% humidity
• there are a couple of inches of snow on the ground and your phone is turning off since it's so cold
• you have a slight injury or pain
• work or family obligations are higher than normal
• you're traveling

Also, this is the step minimum. You may be doing other exercise like swimming or cycling or strength work that won't show up.

Setting a step floor is probably most helpful for folks who work from home or work desk jobs. I feel that it keeps me honest. "Hmm, yeah I only got like 2000 steps today, need to move around a little!"

Typically I pick up a few thousand steps just by walking around the house, doing errands, etc. After doing the step goal for a while, I found out that I walk around 100 steps a minute. I know a few routes around my house that take 5, 10, 15, 20, 30, 45, 60 minutes, so it makes it easier to get close to the goal based on how many more steps I need.

Setting yourself up to succeed

To maintain a long streak, you've got to minimize your chances to fail. Identify the most common reasons for failure and try to mitigate.

Forgetfulness is probably my biggest enemy. One thing leads to another and it just sort of slips away. Setting a few alarms/reminders at night and snoozing until I hit the goal has been the most helpful for me. After a while, it becomes part of a nightly mental check.

Since I can't log steps if the watch is out of battery, I monitor the watch battery and bring the charger on trips or charge it before going if it's getting close to empty.

Based on the walking volume, I try to get good shoes and purchase new ones every few months. If you get random aches (knees, back, etc.) then it might be a good time to switch.

After being cold a few times and reluctant to walk, I got this gear for the elements like warm gloves and this balaclava after reading this review:

I work at an airport in Indiana. As you can I imagine it is super cold in winter and the winds oh my. It is an airport so nothing blocking those winds. We all survive my dressing in layers and not just a few. On average we are wearing 5 layers minimum. This hat is the best combo the built in neck gator protects my nose and mouth. So that it does not hurt to breath. The hoodie in it keeps the wind out my face. Nothing worse then those super cold nights like we just had with the artic polar. I was working in -25 and the winds make you tear up the cold made those watery eyes freeze yes my eyelashes and all froze like ice cycles….

After a few years and a few Vivofit watches, I wanting something more durable. I ended up upgrading to the Garmin Instinct 2 and that has been a positive change due to the heart rate tracking while offering roughly month-long battery life on a single charge.

If I accidentally forgot or missed the goal by a few steps, I try not to take failure too seriously. I got way more steps than I would have otherwise, I'm helping keep my body healthy, and look at it as a chance to start a new (potentially even longer) streak.

I could see a treadmill being in my future since it would enable me to get steps in inclement weather more easily.

Conclusion

Having a daily step floor has worked for me pretty well. I've missed a few days here and there, but feel like it's been a positive change and hope to continue it for the rest of my life.

Identify an issue

There are two main ways that I identify issues on code repos.

When I evaluate a new (to me) project, I need to figure out whether it will meet my needs. Often this will be functionality, but I also want to determine how well supported the project is. I will usually look at:

• the README / wiki
• when the repo was created and when it was last updated
• a few of the most recent commits
• the repo's issues / pull requests tab (including recently closed ones)

These give me a good sense of the level of activity on the project. For example:

• Is it maintained by one person, a team, or has it been mostly abandoned? (To be fair, some older projects will have lower activity since they are more stable.)
• Are there are a lot of issues or pull requests that have lingered without resolution?
• Does it seem to have enough performance, security, or other -ilities?
• Also, the repo itself may be deprecated or point to other alternatives to consider.

As part of this investigation, I typically skim through some of the open issues to check if there are any critical things that I need to be aware of or that might impact my application. This post has a good example of where this habit was useful for identifying a known issue that impacted my project.

The second way to identify issues is to actually use the code. There are a handful of items that I commonly find:

• unclear documentation or typos
• broken documentation links
• setup instruction improvements
• unclear error messages
• incompatibility with other packages or newer language versions

These are all helpful to fix. It helps out other developers for a small time commitment. Observing the amount of small frictions also provides useful information about the repo.

Find or create an issue

My goal at this point is to start or advance a conversation about the issue.

If there's an existing open issue, I prefer using that to keep things centralized.

If the issue is quick, obvious, or low risk fix, then I would usually create a pull request with that change. It can be quick: fork, make the change (even using the GitHub editor), and then submit a PR.

Otherwise, I typically create a new issue. This gives me a chance to start a conversation around whether this is something that needs to be fixed, whether a pull request would be welcome, etc. Other people might have have run into this issue and know a fix, or will run into it in the future.

If I'm creating the issue, I write up as clear of a description of the issue as I can. General notes:

• Start by thanking the maintainers for their work and say how the project is useful to you or how it appears promising
• Describe the issue at a high level
• Minimal reproduction of the issue
• Include any system details (other libraries, versions, platform, etc.)
• If I've looked into the code, I may provide some ideas of where the problem lies

If the path to fixing is not clear, I like to ask if they also think this is an issue and whether they'd be open to a fix. This is useful since sometimes I won't hear back, and sometimes I might learn something that would save time (it's not a good fit for the project, it's actually really hard, it is planned for the next version or already released, etc.)

Getting buy-in for a potential fix also increases the speed / likelihood of it eventually getting merged. I think it's more likely that someone will review your changes if they've already agreed they would be useful.

General tone notes:

• Never be demanding / condescending. Open source is typically unpaid work for someone, and may not be their current focus. The status quo is that most issues are not commented on, or even resolved, so any communication is appreciated.
• I assume I am fallible and my issue could be something that's due to my specific setup, ignorance, or other issues.

If you're responding to an existing issue, you can follow some of these steps as well, especially if they were missing from the original post. I usually try to either add some details or move the conversation along. Things like "+1!" aren't usually helpful (can use emoji reactions for that kind of feedback.)

Consider fixing the problem

If the problem is a blocker or important and I have an angle to fix, I often try to fix the problem. Sometimes I don't have enough knowledge. It's possible that there's another repo or a fork that will get around the issue, so I might not have to fix it. Even so, opening the issue is useful since someone else might be able to fix it.

Typically the reference to this library from our code will be in a package file like package.json, Gemfile, etc. The eventual goal is to be able to update to the latest version of the library. The more special cases we have in our package file (pointing to a fork, pointing to a specific branch/revision), the harder it will be to upgrade the library and the more likely we are to fall behind on security updates or new features.

In practice, the iteration usually looks like:

• Point to a fork of the project with the fix
• Create a PR of the project
• Point to the master branch of the project once it's merged
• Point to the latest revision once it is released

So the first step is to create a fork of the project. You can usually point your main project development environment to that fork for testing. Worst case, we can test the change locally and potentially get a fix weeks or months before it's officially merged. Best case, our code will get merged and make the world a better place.

Fixing the problem

Usually I first run the tests for the project. This helps make sure that we don't break the code when fixing our change. If there are broken tests or docs, can fix those and make a separate PR. Here is a good example of a PR that fixes tests.

When making the fix, I try to consider how to write tests or change tests to cover the behavior in question. It's typically a faster feedback loop than testing from my main application directly. This also adds to confidence, which helps get a more timely merge.

I like to consider whether there are any potentially breaking changes like API changes. This saves the maintainer a step and develops a bit of empathy for the review process.

When creating a pull request, reference the original issue. This will usually save time since the issue should be documented and you can discuss the solution and any tradeoffs.

Building confidence

After you've made a good change, the outcome of the rest of the project is more about communication and trust-building. This includes the communication before the fix is ready.

My general approach involves imagining I am the maintainer of a system that hundreds or thousands of projects depend on. The projects want the next release of the project to work! And I am on the hook if something goes wrong. What message would you rather receive?

1. Here are some changes to fix X. It works on my machine!

2. Here are some changes to fix X. Here's what I did and here's why. I believe this should work since I added some tests and have been running this on my production project for the last couple of days with no issues. One thing I'm not sure about is Y, but I think this should not be a blocker given that it is also an issue in Z. I believe this does not contain any breaking API changes.

I far prefer the second message, as it demonstrates more thoughtfulness and knowledge of the system. (This reminds me a bit of some of the principles of "Turn the Ship Around!")

Shepherd the PR

Sometimes your PR will be accepted quickly. But the reality is that most open source maintainers are busy or this project may not be a high priority for them.

So your goal at this point is to shepherd the PR through the merge process. Typically this is going to look like:

• responding to review comments / questions / requested revisions
• always having a next step or responsible person identified

If someone says they'll look at it tonight, tomorrow, this weekend, etc., I like to follow up with them a day or two after the last date of the range passes. This gives them a bit of leeway so it doesn't feel like you're hounding them, while still being clear that they own the next step so it doesn't fall through the cracks.

Also, you may need to follow up on getting a release. For example, going from v1.3 -> v1.4 in the library. Just merging to the main branch is often insufficient, since often people will point to the latest released version of the code.