A nice, notarized program, that makes adding a wallpaper folder as easy as /usr/local/bin/wallpaper-folder add ~/Pictures/Wallpapers

AI Summary

The article explains how macOS wallpaper folder handling changed in macOS 26 and how that broke simple scripted approaches admins used to add brand or custom wallpaper collections. Previously you could drop images into /Library/Desktop Pictures (which placed them after built-ins) or add a user folder entry in ~/Library/Preferences/com.apple.systempreferences.plist (DSKDesktopPrefPane:UserFolderPaths) using tools like PlistBuddy; those techniques worked across macOS 13–15.

In macOS 26 the wallpaper configuration moved into a container at ~/Library/Containers/com.apple.wallpaper.extension.image/ with embedded plists and a WallpaperAgent daemon, making shell-based edits impractical. To address this, the author created WallpaperFolderManager, a Swift utility/package that generates the required files and encoded plists, restarts cfprefsd and WallpaperAgent, and exposes commands to add, list, and remove wallpaper folders. It’s available as a signed notarized pkg, standalone binary, or Swift package, has options for verbose output and skipping service restarts, and was tested on macOS 15 and 26 (with fallback behavior for 13–15).

Source: TIL: Adding custom wallpaper folders to macOS

Kyle Daigle, COO of Github, responding to an tweet with some data about the insane amount of code GH sees as the result of AI:

There were 1 billion commits in 2025. Now, it’s 275 million per week, on pace for 14 billion this year if growth remains linear (spoiler: it won’t.)

GitHub Actions has grown from 500M minutes/week in 2023 to 1B minutes/week in 2025, and now 2.1B minutes so far this week.

I learned, in the light of the axios compromise that a good deal of package managers support setting a minimum release age for packages:

~/.npmrc
min-release-age=7 # days
ignore-scripts=true

~/Library/Preferences/pnpm/rc
minimum-release-age=10080 # minutes

~/.bunfig.toml
[install]
minimumReleaseAge = 604800 # seconds

For Python with uv (which by now should be the default):

~/.config/uv/uv.toml
exclude-newer = "7 days"

Alas, pip only supports filtering by date, and only in version v26.0 and later, with:
pip install --uploaded-prior-to=2026-03-31 SomePackage.

That is a bit annoying so a shortcut for the 7-day gating would be
pip install --uploaded-prior-to=$(date -v-7d -u "+%Y-%m-%d") SomePackage.

There’s also pip-time-machine which helps you find out version for packages before a certain date.

The first step of Visual Studio Code install is deceptively simple: download the .deb file, double-click to open.

Trying to log into accounts causes a notification/error:

You’re running in a GNOME environment but the OS keyring is not available for encryption. Ensure you have gnome-keyring or another libsecret compatible implementation installed and running.

The keyring troubleshooting page provides some clues but it’s a bit clumsy to figure it out.

1. Problem 1: libsecret is not installed on a fresh Linux Mint v22.3.
   Solution: install with apt install libsecret-1-0 libsecret-1-dev libsecret-tools (not sure all of them are required).
2. A bit buried in the docs is this bit: “and ensure the default keyring (usually referred to as Login keyring) is unlocked”.
   Problem 2: there was no “Login” password keyring visible in Seahorse (the keyring manager).
   Solution: First, it’s very possible a restart (of gnome-keyring) after installing libsecret might have auto-fixed this issue, but I went ahead to try to create that and failed: the UI was not showing the new keyring, so restart was in the cards anyway.
   After restarting the computer, I was able to create the new Login password keyring and Visual Studio Code worked without any issues. It didn’t even require the --password-store="gnome-keyring" argument or startup setting.

Also thanks to this SO answer and this one too.

Claude has documentation on this, but I find the Azure Foundry’s documentation more useful because the instructions are more up-to-date with their UI (currently changing once more).

The one thing I wasn’t so comfortable with is setting the keys and all in env vars. If any process has access to the environment, it can extricate these values, even by mistake, and that’s not desirable.

Luckily, the ~/.claude/settings.json file support settings these, so here’s my example:

{
  "env": {
    "CLAUDE_CODE_USE_FOUNDRY": 1,
    "ANTHROPIC_FOUNDRY_BASE_URL": " https://<project-name>-resource.services.ai.azure.com/anthropic",
    "ANTHROPIC_FOUNDRY_API_KEY": "<key>",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "claude-sonnet-4-6",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "claude-opus-4-6"
  }
}

Couple of notes:

1. You can set either ANTHROPIC_FOUNDRY_RESOURCE or ANTHROPIC_FOUNDRY_BASE_URL. It’s a bit confusing because you create a project, say named foo-bar in Foundry, but the resource name is foo-bar-resource.
   At the end of the day copying the URL from the Foundry site seemed more straightforward.
2. I think it’s advisable to set names of the models deployed explicitly, hence ANTHROPIC_DEFAULT_SONNET_MODEL because Claude Code may have different defaults.
   I got this message on my first run: “The model claude-sonnet-4-5 is not available on your foundry deployment. Try /model to switch to claude-sonnet-4, or ask your admin to enable this model.”, and, fair enough, I had claude-sonnet-4-6 deployed.