It looks like claude-code does a git fetch at startup, which requires SSH if the repository was cloned that way. To fix it, set this environmental variable:

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

From the manual:

CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC: Equivalent of setting DISABLE_AUTOUPDATER, DISABLE_BUG_COMMAND, DISABLE_ERROR_REPORTING, and DISABLE_TELEMETRY

I haven’t tried scoping it down to one of these variables, let me know if you do! Meanwhile, this should also prevent claude-code from asking for feedback during a session.

Although the problem was real, my post felt overly negative, not constructive, and wrong. Instead of publishing it, I just opened an issue in cloudflare-docs.

The maintainers have now kindly fixed the issue. Anyone can use any Ruby version in a Cloudflare Pages build. If the worker doesn’t have that version available, it will automatically download it and compile it (in which case, the build might take a bit longer).

As for me, this means I can pin my .ruby_version to one that is cached in nixpkgs so that I can quickly start writing on low-powered devices.

To add a .p12 certificate to ChromeOS’ certificate manager:

1. Navigate to chrome://certificate-manager
2. → “Your certificates”
3. → “View imported certificates from ChromeOS”
4. → “Import and bind”
5. Select your certificate from the file picker
6. Enter your certificate’s password

“Import and bind” stores the certificate on the device’s Trusted Platform Module (TPM).

It might be possible to also store the certificate on a Yubikey through the Personal Identity Verification (PIV) app and then use it on a Chromebook through the Smart Card Connector and a middleware. I haven’t tried this approach yet, but I hear it is tricky on non-enterprise devices.

You can see the result as follows:

notify-send --app-name="baguette-nixos" "Hello, ChromeOS!"

An example notification

The Slack troubleshooting guide suggested to check that Safari’s preferences allowed notifications from the Slack website. But I never got the prompt to allow that in the first place: app.slack.com was missing from the settings, both in Safari and in macOS’ notification center.

Slack’s troubleshooting guide for Safari.

To fix it, I manually requested the permission to show notifications from the developer console of Slack’s tab:

Notification.requestPermission().then(permission => {
  if (permission === 'granted') {
    new Notification('Hello!', {
      body: 'This is a notification from Safari',
      icon: '/path/to/icon.png'
    });
  }
});

After that, notifications started to work.

I generally don’t like having long-lived API keys somewhere on-disk, because a rogue executable (or an LLM falling for prompt injection) could easily leak them. This is the main reason why I don’t use the popular gh CLI application, which relies (by default) on a very privileged access token stored on disk.

To avoid this issue altogether, I often work inside throwaway VMs. The downside is that, each time, I will need to re-authenticate to those services requiring local credentials (including llm-openrouter).

Luckily, OpenRouter allows to programmatically provision API keys, which makes re-authentication fast and easy. I wrote and host a simple openrouter-provisioner on one of my nodes, where it is only accessible through Tailscale (configured on the host, not the guest VM). By default, it will provision and return API keys expiring after 24h.

With that in place, I can quickly get things running on a new VM:

llm keys set openrouter --value \
  $(curl -s -X POST https://openrouter | jq -r '.api_key')

1. Package scripts into executables with proper shebangs (e.g., Python).
2. Bundle any dependencies.
3. Perform checks/lints (e.g., through flake8)

I am using it in my openrouter-provisioner as follows:

server = pkgs.writers.writePython3Bin "openrouter-provisioner" {
  flakeIgnore = [
    "E501" # line too long
  ];
} (builtins.readFile ./openrouter.py);

When an LLM originally suggested this snippet, I thought it was hallucinating because I couldn’t find any reference in the manual. Then, when challenged, the LLM returned the source for the writers library. LLMs are obviously not suited for all tasks, but this is an example of something they are excellent at: they will easily discover and use less-known library features by going through the source code when the documentation is lacking.

In this particular case, the writers library includes documentation comments for most of the derivations, but none of them make it in the overall manual. I was about to open an issue but then discovered that there’s already one dating back to 2020.

The writers

In case it’s useful, this is the Markdown documentation that would be generated and below is a list of all the included writers (some are missing from the docs):

When using nvim, :h lsp-log provides these useful commands to trace protocol messages:

vim.lsp.set_log_level 'trace'
require('vim.lsp.log').set_format_func(vim.inspect)

The problem is that tracing slows down the editor, bloats the logfile, and won’t have the best ergonomics to parse the messages.

Instead, I have written and improved over time a small Nix derivation that wraps the LSP to dump its standard input, output, and error to files so that I can easily take a look at them later.

Here it is, in case it’s useful to anyone:

wrapLSP =
{
  lsp,
  cmd ? (pkgs.lib.meta.getExe lsp),
}:
pkgs.writeShellApplication {
  name = lsp.meta.mainProgram;
  runtimeInputs = [
    lsp
  ];

  text = ''
    coproc LSP_SERVER { ${cmd} "$@" 2> /tmp/${lsp.name}_error.log; }

    # first some necessary file-descriptors fiddling
    exec {srv_input}>&"''${LSP_SERVER[1]}"-
    exec {srv_output}<&"''${LSP_SERVER[0]}"-

    # background commands to relay normal stdin/stdout activity
    tee /tmp/${lsp.name}_input.log <&0 >&''${srv_input} &
    tee /tmp/${lsp.name}_output.log <&''${srv_output} &

    while true; do sleep infinity; done
  '';
};

To use it, call it with an LSP as an argument (e.g., wrapLSP pkgs.ctags-lsp), build the derivation, and then add the result to PATH: PATH=$(readlink -f result/bin)/:$PATH when launching your editor.

I also like my pipelines deterministic so that upstream releases don’t break them by mistake. For this, I use Nix to package things up.

Unfortunately, when using the mlx Nix derivation available in nixpkgs, the CLI would stall and the inference process would eventually SIGSEV. That’s because that derivation does not build with Metal support:

# NOTE The `metal` command-line utility used to build the Metal kernels is not open-source.
# To build mlx with Metal support in Nix, you'd need to use one of the sandbox escape
# hatches which let you interact with a native install of Xcode, such as `composeXcodeWrapper`
# or by changing the upstream (e.g., https://github.com/zed-industries/zed/discussions/7016).

The sandbox escape hatch sounds scary. Instead, I fixed it by pulling wheels from Pypi (it turns out that mlx and mlx-metal are required) and patching them to work with Nix.

If anyone needs it, here is the resulting derivation. Below it is in action:

echo "Hi" | nix shell .#llm -c llm prompt -m mlx-community/Llama-3.2-3B-Instruct-4bit

How can I assist you today?