DEV Community: Felipe Philipp

claude-statusline: a configurable status line for Claude Code

Felipe Philipp — Tue, 17 Mar 2026 15:10:01 +0000

Claude Code lets you customize the status line at the bottom of your terminal. The default suggestion is a bash script, which works but gets clunky fast and difficult to maintain for more complex features.

There are other tools out there that solve this (more on that below), but none written in Go. I think Go is the right fit here: fast, compiles to a single binary, and cross-platform out of the box, given my setup uses Mac/Linux/Windows. I’m a big fan of Starship, and it heavily inspired the design: presets, format strings, per-module config and so on.

So I built claude-statusline:

What it shows

The default format displays five modules:

format = "$directory | $git_branch | $model | $cost | $context"

directory: current working directory, truncated to the last 3 segments
git_branch: current branch, with an indicator when you’re inside a git worktree
model: which Claude model is running
cost: session cost in USD, color-coded by thresholds (yellow at $1, red at $5)
context: context window usage as a progress bar with percentage (yellow at 50%, red at 90%)

There are two more modules disabled by default: session_timer and lines_changed. You can enable them in the config.

Themes

claude-statusline ships with 6 built-in presets:

Preset	Description	Nerd Font
`default`	Flat with pipes, standard colors	No
`minimal`	Clean spacing, no separators	No
`pastel-powerline`	Pastel powerline arrows	Yes
`tokyo-night`	Dark blues with rounded powerline	Yes
`gruvbox-rainbow`	Earthy rainbow powerline	Yes
`catppuccin`	Catppuccin Mocha powerline	Yes

To switch themes, set the preset field in your config:

preset = "tokyo-night"

Preview all of them with mock data:

claude-statusline themes

Making it your own

The config lives at ~/.config/claude-statusline/config.toml. You can start from a preset and override individual modules:

preset = "catppuccin"

[cost]
thresholds = [
  { above = 2.0, style = "yellow" },
  { above = 10.0, style = "red" },
]

[context]
bar_width = 10

Styles support named colors, hex values, 256-color codes, and attributes:

[model]
style = "fg:#11111b bg:#cba6f7 bold"

Rearranging the format string or adding inline styled text also works:

format = "$model | $directory | $git_branch | [$cost](dim)"

Installation

With Homebrew (recommended, keeps updates simple):

brew install felipeelias/tap/claude-statusline

Or with Go:

go install github.com/felipeelias/claude-statusline@latest

Then add it to your Claude Code settings (.claude/settings.json or global):

{
  "statusLine": {
    "type": "command",
    "command": "claude-statusline prompt"
  }
}

Generate a starter config with claude-statusline init, and use claude-statusline test to iterate on your config without running Claude Code.

Alternatives

The awesome-claude-code list has other options worth checking out:

claude-powerline: vim-style powerline with usage tracking and themes
CCometixLine: written in Rust, with interactive TUI configuration
claudia-statusline: also Rust-based, with persistent stats tracking and cloud sync
ccstatusline: customizable formatter with token usage and metrics

HookLab - Watch your Claude Code hooks in real time

Felipe Philipp — Sat, 28 Feb 2026 18:51:05 +0000

Claude Code recently added HTTP hooks. Instead of shell scripts, you can point hook events at a URL. I built HookLab to play with that.

It’s a live dashboard. Every hook event shows up in the browser as it happens: which tools are being called, what arguments they get, what comes back. You can filter by event type, tool, session, and expand any row to inspect the full payload.

To run it:

services:
  app:
    image: ghcr.io/felipeelias/hook-lab:latest
    ports:
      - "4000:4000"
    volumes:
      - hook_lab_data:/app/data
    environment:
      SECRET_KEY_BASE: ${SECRET_KEY_BASE}
      DATABASE_PATH: /app/data/hook_lab.db
      PHX_HOST: localhost

volumes:
  hook_lab_data:


export SECRET_KEY_BASE=$(openssl rand -base64 64)
docker compose up -d

Then point your hooks at it. The README has the full settings.json config you need.

Built with Phoenix LiveView and SQLite. Next version will let you block or modify hook events based on rules.

You Should Be Versioning Your ~/.claude Config

Felipe Philipp — Fri, 27 Feb 2026 20:08:56 +0000

If you’ve been using Claude Code for a while, you’ve probably accumulated a decent amount of configuration: settings, skills, custom agents, CLAUDE.md instructions. Losing all of that would be annoying.

The fix: git init inside ~/.claude, with some caveats.

What lives in ~/.claude

Based on the official docs, here’s what’s worth versioning:

CLAUDE.md
settings.json
skills/**/SKILL.md
agents/<name>.md
commands/<name>.md
statusline.sh

What to ignore

Claude Code generates transient data that you should ignore. Add this to your .gitignore.

# Credentials
.credentials.json
credentials.json

# Internal state
.claude.json
.claude.json.backup.*
security_warnings_*.json
stats-cache.json
mcp-needs-auth-cache.json

# Session data
history.jsonl
backups
cache
debug
file-history
paste-cache
session-env
shell-snapshots

# Agent and team state
plans
plugins
tasks
teams
todos

# Telemetry
statsig
telemetry
usage-data

# IDE integration
ide/

Note about projects

The projects/ directory contains per-project auto-memory and conversation logs. Claude Code recently enabled memory per project, which is worth adding to git. The easiest approach is to ignore the log files instead:

projects/**/*.jsonl
projects/**/*.txt

Quick setup

Remember to push it to GitHub or GitLab, below is an example with GitHub:

cd ~/.claude
git init
git add .gitignore CLAUDE.md settings.json
git add skills/ agents/ commands/ statusline.sh 2>/dev/null
git commit -m "feat: initial claude config"
gh repo create claude-config --private --source=. --push

That’s it.

Elixir Toolbox - Major Update

Felipe Philipp — Fri, 27 Feb 2026 10:07:36 +0000

I’ve been working on Elixir Toolbox quite a bit lately and wanted to share what’s new:

More categories: ~150 now, including AI/LLM sections (and more)
JSON API: the aggregated data is now exposed for anyone to query
New trending page, showing packages by recent downloads
llms.txt and llms-full.txt endpoints so LLMs can read the catalog: try asking your AI agent to “find me the best Elixir package for X using elixir-toolbox.dev”
Complete UI refresh, using DaisyUI
GitLab support

This is a passion project. I use it to keep my Elixir skills sharp, and hopefully it helps others too. Check it out!

Perfect Claude Code Notifications Setup with Tailscale and ntfy

Felipe Philipp — Thu, 26 Feb 2026 08:08:54 +0000

If you’re like me and have been hooked into running Claude Code on your phone, running several sessions in parallel like Boris, you may have noticed that it is easy to lose track of what is going on on all those sessions. You may go away for a sec, distracted by Minecraft parkour videos and forget that Claude is waiting for your input.

Idea

Claude Code comes with a notification hook. Some terminals support it natively (iTerm2, Kitty, Ghostty) but most don’t, and even when they do, it’s a system notification which is easy to miss if you step away.

The idea is to get a phone notification when Claude Code needs your input. I considered a few options, and I ended up choosing ntfy as the notification provider.

To make sure that everything stays private, I decided to host ntfy on my machine and use Tailscale as my private network.

I was also tired of dealing with bash scripts. I kept running into compatibility issues between Mac, Linux and Windows, so I built a small tool to solve that (but you can still use bash).

Requirements

The only thing you need is a Tailscale account and Docker for that. If you want to go with bash, it helps to have jq installed.

Step 0: Project Structure

Here are the files you’ll need:

my-infra/
├── .env
├── compose.yml
└── config/
    └── ntfy.json

Step 1: Configure Tailscale ACL

Go to the ACL editor and add a tag:container tag:

"tagOwners": {
  "tag:container": ["autogroup:admin"]
}

Step 2: Create an OAuth Credential

Go to Trust & Credentials to generate a new OAuth credential.

Click Credential → OAuth
Grant auth_keys scope with write permission
Select tag tag:container
Copy the client secret (tskey-client-...)

OAuth works better because the regular auth keys expire in 1–90 days. OAuth client credentials don’t expire and the container re-authenticates automatically on restart.

Now add the OAuth key to your .env:

TS_AUTHKEY=...

Step 3: Docker Compose

Your compose will look like below. It uses the tailscale/tailscale and binwiederhier/ntfy images and relies on Tailscale sidecar pattern where it exposes your Docker containers as machines in the tailnet. This is really useful because you can reach the Docker container by name directly, the sidecar will proxy the request, handle HTTPS, etc.

name: my-infra

services:
  ts-ntfy:
    image: tailscale/tailscale:latest
    container_name: ts-ntfy
    hostname: ntfy
    restart: unless-stopped
    environment:
      - TS_AUTHKEY=${TS_AUTHKEY}?ephemeral=false
      - TS_EXTRA_ARGS=--advertise-tags=tag:container --reset
      - TS_SERVE_CONFIG=/config/ntfy.json
      - TS_STATE_DIR=/var/lib/tailscale
      - TS_USERSPACE=false
    volumes:
      - ts-ntfy-state:/var/lib/tailscale
      - ./config:/config
    devices:
      - /dev/net/tun:/dev/net/tun
    cap_add:
      - net_admin

  ntfy:
    image: binwiederhier/ntfy
    container_name: ntfy
    restart: unless-stopped
    command: serve
    environment:
      NTFY_BASE_URL: "https://ntfy.<your-tailnet>.ts.net"
      NTFY_UPSTREAM_BASE_URL: "https://ntfy.sh"
    network_mode: service:ts-ntfy
    depends_on:
      - ts-ntfy

volumes:
  ts-ntfy-state:

Note the NTFY_UPSTREAM_BASE_URL setting. This forwards push notifications through ntfy.sh’s Firebase/APNs infrastructure for instant mobile delivery. Without it, notifications can be delayed by minutes or hours.

Step 4: Tailscale Serve Config

config/ntfy.json — this tells Tailscale to proxy HTTPS to ntfy’s port 80:

{
  "TCP": {
    "443": {
      "HTTPS": true
    }
  },
  "Web": {
    "${TS_CERT_DOMAIN}:443": {
      "Handlers": {
        "/": {
          "Proxy": "http://127.0.0.1:80"
        }
      }
    }
  }
}

Step 5: Start It

docker compose up -d

Give it ~15 seconds for the TLS certificate to be provisioned. ntfy is now available at https://ntfy.<your-tailnet>.ts.net from any device on your tailnet.

Tip: Your tailnet name (the taila2944f part) can be changed to something more readable in DNS settings. Also make sure that “HTTPS Certificates” are enabled.

Step 6: Subscribe on Your Phone

You need to install the ntfy app, available on Google Play and the App Store. Once installed you need to subscribe to a topic with your server URL. For example:

Add claude-code as the topic
Choose the custom server: https://ntfy.<your-tailnet>.ts.net

You can make a quick test with:

curl -s -H "Title: Test" -d "Hello from the terminal!" "https://ntfy.<your-tailnet>.ts.net/claude-code"

Step 7: Claude Code Hook

Now wire up Claude Code to send notifications through ntfy. You have a few options:

Option 1: claude-notifier

This is the tool I built to solve that: claude-notifier. It handles multiple notification channels, sending to ntfy but also to native system notifications (in Mac, via terminal-notifier).

felipeelias / claude-notifier

Notification dispatcher for Claude Code hooks

claude-notifier

Notification dispatcher for Claude Code hooks. Reads JSON from stdin, fans out to all configured notification channels concurrently. Single static binary, compiled-in plugins, TOML configuration.

Why

Claude Code has notification hooks that run a shell command when the agent needs your attention. Most people write a bash script that curls ntfy or sends a desktop notification. That works fine for one channel on one machine.

It gets annoying when you want notifications on your phone and your desktop, or you move to a different OS and have to rewrite the script, or you want high priority for errors but low priority for routine updates.

claude-notifier is a single binary that handles all of that:

Sends to multiple channels from one hook (ntfy, desktop, Slack, etc.)
Same binary and config file across Linux, macOS, and Windows
Always exits 0 so it never breaks your hook
claude-notifier init, edit the…

View on GitHub

Install it:

brew install felipeelias/tap/claude-notifier

Generate the config:

claude-notifier init

This creates ~/.config/claude-notifier/config.toml. Point it to your ntfy server:

[[notifiers.ntfy]]
url = "https://ntfy.<your-tailnet>.ts.net/claude-code"
title = "Claude Code ({{.Project}})"

Then add the hook to ~/.claude/settings.json:

{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "claude-notifier"
          }
        ]
      }
    ]
  }
}

Same binary and config on every machine. Run claude-notifier test to verify it works.

Option 2: Bash script

You can still go with a bash script if you want. Create ~/.claude/hooks/notify.sh:

#!/usr/bin/env bash
set -euo pipefail

# Convert backslashes for Windows path compatibility
INPUT=$(cat | tr '\\' '/')
PROJECT=$(printf '%s' "$INPUT" | jq -r '.cwd // empty' | xargs basename 2>/dev/null || echo "")
HOOK_TITLE=$(printf '%s' "$INPUT" | jq -r '.title // empty')
MESSAGE=$(printf '%s' "$INPUT" | jq -r '.message // "Done"')

if [-n "$HOOK_TITLE"]; then
  TITLE="$HOOK_TITLE"
elif [-n "$PROJECT"]; then
  TITLE="Claude Code ($PROJECT)"
else
  TITLE="Claude Code"
fi

curl -s \
  -H "Title: $TITLE" \
  -d "$MESSAGE" \
  "${NTFY_URL}/claude-code" > /dev/null 2>&1 || true

Make it executable (chmod +x ~/.claude/hooks/notify.sh) and add to ~/.claude/settings.json:

{
  "env": {
    "NTFY_URL": "https://ntfy.<your-tailnet>.ts.net"
  },
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/hooks/notify.sh"
          }
        ]
      }
    ]
  }
}

This requires jq (brew install jq, apt install jq, or winget install jqlang.jq).

Putting all together

If all is working you should see this:

Troubleshooting

If the notification says “New message”, make sure that all devices (including your phone) are on the same Tailscale network. If they are and you’re still not getting notifications, you can always ask Claude to help you debug it.

Denormalized indexing with elasticsearch-rails

Felipe Philipp — Sat, 06 Jan 2018 11:15:47 +0000

One of the biggest advantages of using Elasticsearch it is because it's fast even if you have very complex documents with many attributes coming from different models.

Achieving that requires you to denormalize those models into a single index and it's your responsibility as a developer to keep it consistent.

That reveals some interesting challenges, let's take a look.

Blog in 5 minutes

Imagine we have a simple has_many/belongs_to relationship between Posts and Authors. Our end goal is to be able to search by posts from a specific author by its name.

Assuming that you have a basic Rails application with elasticsearch-rails installed and Elasticsearch running, our models will look like this:

# db/migrate/...
class CreateModels < ActiveRecord::Migration[5.1]
  def change
    create_table :authors do |t|
      t.string :name
      t.string :email
      t.timestamps
    end

    create_table :posts do |t|
      t.string :title
      t.text :body
      t.datetime :published_at
      t.references :author, foreign_key: true
      t.timestamps
    end
  end
end

# models/author.rb
class Author < ApplicationRecord
  has_many :posts
end

# models/post.rb
class Post < ApplicationRecord
  include Elasticsearch::Model
  include Elasticsearch::Model::Callbacks

  belongs_to :author
end

The Post model will be our entry point to manage changes in the index. I'm not going to get into details of how the elasticsearch-rails gem works, you can check its documentation on the github repository.

Assuming you imported all posts and users, you can perform full-text search with:

Post.search('example').records.all

That will let you search for every attribute in the Post model, but not by author names.

Extending

Now for the fun part. Let's add author information in the same index as the posts. This will help us achieve our goal of searching by author name.

You'll need to define a custom mapping and a how to index it by overriding #as_indexed_json method:

class Post < ApplicationRecord
  # ... snipped

  mapping dynamic: :strict do
    indexes :id,           type: :long
    indexes :title,        type: :text
    indexes :body,         type: :text
    indexes :published_at, type: :date
    indexes :created_at,   type: :date
    indexes :updated_at,   type: :date
    indexes :author do
      indexes :id,   type: :long
      indexes :name, type: :text
    end
  end

  def as_indexed_json(options = {})
    self.as_json(
      options.merge(
        only: [:id, :title, :body, :published_at, :created_at, :updated_at],
        include: { author: { only: [:id, :name] } }
      )
    )
  end
end

After changing this, you must recreate the index and re-import the data:

Post.__elasticsearch__.create_index!(force: true)
Post.import

Then, there is one bug 🐞

If you use your application for a while, you'll notice that if you change the author of a post, this change won't be reflected in Elasticsearch.

After some debugging, it turns out that elasticsearch-rails gem only indexes the attributes that changed via ActiveModel::Dirty module. That doesn't work for our case since author is not an attribute of a post.

Simply put, when you modify the author of a post, the attribute that changes is the author_id. After you save the post, the gem compares which attributes changed against the hash returned by #as_indexed_json. Since our changes are now represented as an author hash, the gem can't find the author_id there.

There are a couple of ways to solve this:

Drop the Elasticsearch::Model::Callbacks module and then handle the indexing logic yourself
Force a change by adding the author key as a change whenever the author_id changes
Ignoring all changes completely

I choose to go with solution #2, which looks like this:

class Post < ApplicationRecord
  # ... snipped

  before_save :force_index

  def force_index
    if changes['author_id']
      attr = :@__changed_model_attributes
      old_changes = __elasticsearch__.instance_variable_get(attr)
      __elasticsearch__.instance_variable_set(attr, old_changes.merge!('author' => true))
    end
  end
end

It's a hack, it changes the internals of the elasticsearch-rails gem and I'm not very happy with the solution. I went this way to keep the functionality of indexing only changed attributes however, this can get pretty cumbersome to maintain.

If you don't care about this optimization, you can go with #3 and always force the index by clearing the @__changed_model_attributes instance variable:

def force_index
  __elasticsearch__.instance_variable_set(:@__changed_model_attributes, nil)
end

With either approach, if you change the author the changes will be reflected in Elasticsearch.

And then, there are two bugs 🐞🐞

After the hint on the previous bug, one would notice that changing the author's name won't reflect on Elasticsearch either! That's because Author model doesn't know anything about indexing itself the Post index.

This is where keeping the consistency on the index gets tricky. There are numerous ways of solving this, each of them with its own drawbacks. To keep things simple I'm going to suggest one solution that works well and doesn't use any other dependency other than Elasticsearch itself 🎉🎉🎉.

We'll use #update_by_query feature which as the name suggests, lets you update various documents that match a query. It has some cool features like being able to work asynchronously, updating documents at its own pace without overloading the cluster and handling conflicts. Check out the documentation here.

Let's take advantage of that to update all posts that belong to a specific author in the background:

# models/author.rb
class Author < ApplicationRecord
  after_commit :update_relations

  private

  def update_relations
    Post.update_authors(self)
  end
end

# models/post.rb
class Post < ApplicationRecord
  # ... snipped

  def self.update_authors(author, options = {})
    options[:index] ||= index_name
    options[:type]  ||= document_type
    options[:wait_for_completion] ||= false

    options[:body] = {
      conflicts: :proceed,
      query: {
        match: {
          'author.id': author.id
        }
      },
      script: {
        lang:   :painless,
        source: "ctx._source.author.name = params.author.name",
        params: { author: { name: author.name } }
      },
    }

    __elasticsearch__.client.update_by_query(options)
  end
end

The code is quite self-explanatory. Any changes in the Author model will trigger an #update_by_query which performs an update for all posts that match the query:

query: {
  match: {
    'author.id': author.id
  }
}

For each match, it will execute the scripted update defined, which simply sets the author name to the one specified in the params:

script: {
  lang:   :painless,
  source: "ctx._source.author.name = params.author.name",
  params: { author: { name: author.name } }
}

You may want to optimize the #update_relations method to only call #update_authors when necessary. Using params let you easily include more attributes in the future and also avoids potential security issues brought by concatenating strings in the source.

Setting wait_for_completion to false will tell Elasticsearch to perform the update asynchronously. This is good if there is a potential case of an author having tons of posts.

Thinking about conflicts

You may have noticed that I set conflicts: :proceed in the updated body. This is to handle a couple of scenarios:

The post is updated

Imagine the case where we update an author's name that has one bazillion posts. That will take a while... There is a chance that any of the author's posts will be updated by somebody else in the meantime.

Before running an #update_by_query, Elasticsearch takes a snapshot of the index and uses the internal versioning scheme to identify such conflicts. If a post is updated after the time when update was "queued" and before it was "run", the post will have a new version, so the #update_by_query will fail for that post. In this scenario, we'd like to skip such conflicts and proceed.

This means that the last update wins and we have the guarantee that the post will have the latest value for the author's name.

Multiple updates to the same author

If somebody updates the author once, then immediately regrets this decision and updates it again to something else, there is a chance that the first update will still be running (considering bazillion of posts). If that's the case, the first update will encounter conflicts, ignore them and move on.

In theory, the second update will always win because it will come after the first one.

Conclusion

Denormalizing data can help you take advantage of Elasticsearch fast querying features, but it has a cost of having to handle concurrent updates to multiple models, which reveals some pretty hard to debug issues and inconsistency.

Note that is a very simple scenario and probably you won't need Elasticsearch if you don't have anything other than that. However, the biggest advantage comes when you have to index many different models in the same document and when doing joins in the database becomes prohibitive.

Originally published at Medium on December 27, 2017.