When the same unusual dialog appears twice within a few days for two different people, you begin to suspect a pattern. This article explores a rabbit hole that involves git, the log and the fickleness of AI.

On 8 March, Guy wondered whether an XProtect update earlier this month could have been responsible for a dialog reading The “git” command requires the following command line developer tools. Would you like to install the tools now? As the request seemed legitimate but its cause remained unknown, we mulled a couple of possible culprits, and he went off to investigate.

Five days later, after he had installed the update to SilentKnight 2.13, Greg emailed me and asked whether that might be responsible for exactly the same request appearing on his Mac. This time, Greg had consulted Claude, which asked him to obtain a log extract using the pasted command
log show --start "2026-03-13 07:07:00" --end "2026-03-13 07:10:00" --style compact --info | grep -E "14207|spawn|exec|git|python|ruby|make"

Armed with that extract, Claude suggested that SilentKight had been the trigger for that dialog.

I reassured Greg that, while SilentKnight does rely on some command tools, it only uses those bundled with macOS, and never calls git even when it’s feeling bored. While I was confident that my app couldn’t have been responsible, I wondered if its reliance on making connections to databases in my Github might somehow be confounding this.

While I knew Claude was wrong over its attribution, the log extract it had obtained proved to be conclusive. Within a few minutes of looking through the entries, I had found the first recording the request for command line tools:
30.212 git Command Line Tools installation request from '[private]' (PID 14205), parent process '[private]' (parent PID 14161)
30.212 git Command Line Tools installation request from '[private]' (PID 14206), parent process '[private]' (parent PID 14161)

As ever, the log chose to censor the most important information in those entries, but it’s dumb enough to provide that information elsewhere. All I had to do was look back to discover what had the process ID of 14161, as its parent. Less than 6 seconds earlier is:
24.868 launchd [pid/14161 [Claude]:] uncorking exec source upfront

Just to be sure, I found matching entries for SilentKnight and the system_profiler tool it called after the attempt to run git:
30.153 launchd [pid/14137 [SilentKnight]:] uncorking exec source upfront
30.336 launchd [pid/14139 [system_profiler]:] uncorking exec source upfront

There was one small mystery remaining, though: why did Claude’s log show command also look for process ID 14207? That was the PID of the installondemand process that caused the dialog to be displayed:
30.215 launchd [gui/502/com.apple.dt.CommandLineTools.installondemand [14207]:] xpcproxy spawned with pid 14207

Following its previous denial, when Claude was confronted with my reading of the log, it accepted that its desktop app had triggered this dialog. Its explanation, though, isn’t convincing:
“the Claude desktop app calls git at launch — likely for one of a few mundane reasons like checking for updates, querying version information, or probing the environment. It’s not malicious, but it’s poorly considered behavior for an app that can’t assume developer tools are present on every Mac.”

In fact, it was Guy who had probably found the real reason, that the Claude app has Github as one of its four external connectors. However, that shouldn’t give it cause to try running the git command, resulting in this completely inappropriate request.

Conclusions

• Claude might know how to use the log show command, but it still can’t understand the contents of the Unified log.
• If you’re ever prompted to install developer command tools to enable git to be run, suspect Claude.
• What a fickle and ever-changing thing is an AI.*

I’m very grateful to Greg and Guy for providing the information about this curious problem.

* This is based on a well-known English translation of a line from Virgil’s Aeneid, Book 4: “Varium et mutabile semper femina”, “what a fickle and ever-changing thing is a woman”. While all of us should dispute that, there’s abundant evidence that it’s true of Claude and other AI.

I’d like to apologise to those of you who ended last week downloading two new versions of SilentKnight, instead of the one that I had intended. This article explains how the second came about.

SilentKnight is heavily dependent on discovering key facts about the Mac that it’s running on. One of the first it needs to know is whether it’s looking at a plain Intel Mac, one with a T2 chip, or an Apple silicon Mac, as that determines how it should go about checking which version of firmware it’s running, and much else.

Over the last five years, SilentKnight has relied on the command-line equivalent of the System Information app, system_profiler. Surprisingly that doesn’t have a single field that draws a clear distinction between those types of Mac. The closest it comes to doing that is the information shown for the Controller item, or
system_profiler SPiBridgeDataType
in Terminal:

• Intel Macs without a T2 chip return no information, as they’re not considered to have a controller in this sense.
• Those with T2 chips return a Model Name of Apple T2 Security Chip.
• Apple silicon Macs give the iBoot (or, from 26.4, mBoot) firmware version number.

While that has worked for five years, for SilentKnight version 2.13 I decided to slightly extend the text it looks for, to ” T2 ” to reduce the chance of false positives now that Apple silicon results are becoming more diverse. That worked fine on my two Intel Macs with T2 chips, but broke weirdly in a MacBook Pro tested by Jan, to whom I’m deeply grateful for the early report of this problem. Jan’s MacBook Pro was thoroughly confused, found and reported the correct T2 firmware but told them it should be running a more recent version of iBoot, for Apple silicon Macs.

It turned out that Jan’s MacBook Pro is running German as its primary language, so instead of reporting Apple T2 Security Chip in system_profiler it returned Apple T2-Sicherheits-Chip, and ” T2 ” couldn’t be found to confirm it wasn’t an Apple silicon Mac. The simple fix was to remove the trailing blank from the search term, which becomes ” T2″.

Although system_profiler can return its information in plain text, JSON or XML formats, its content is the same in all three, with localised text that’s dependent on that Mac’s primary language setting. Besides, its XML is exceptionally verbose, squeezing a few lines of information into 262. I was surprised by this five years ago, when I first came across it when trying to parse the list of Apple silicon security settings.

Here you can see those for a Mac using Dutch localisation. Instead of responses like
Secure Boot: Full Security
using Dutch for your Mac’s primary language turns that into
Secure Boot: Volledige beveiliging
When SilentKnight tries to work out whether your Mac is set to Full Security, that means it would have to look up the response in a dictionary containing every possible language.

Not only that, but these localised responses vary between different sections and data types.

The above responses to system_profiler with French set as the primary language demonstrate that has no effect on Hardware data, where core types are given in English, but changes those in Controller’s Boot Policy. To discover which change, you have to test with many different language settings, as none of this is documented, of course.

At that time I spent several days trying to get an unlocalised response by running system_profiler in an English environment, but that had no effect, and there was no way to bypass this localisation. As this language dependency limits the usefulness of the command tool, I argued that its output shouldn’t be localised at all.

Now, five years later, I have been bitten again, and apologise for putting you through two updates to SilentKnight when there should only have been one.

Previously

Bad design makes macOS a Tower of Babel

Apple silicon Macs are about to undergo change to the numbering of their firmware versions. Accounts from beta-testing of the next minor update to macOS 26 Tahoe, version 26.4, indicate that future firmware will no longer be numbered as iBoot 13822.101.6, but as mBoot 18000.101.6 instead. This has major consequences for my free utility SilentKnight, which checks and reports the version of firmware installed. Version 2.14 should address that change in readiness for the release of the 26.4 update, and is particularly recommended for use on Apple silicon Macs.

This change was first reported in macOS 26.4 beta 2, and has apparently been sustained in the two subsequent beta releases, confirming that it’s an intended change, and not a bug.

There are currently two places in System Information that report a Mac’s firmware version, either the main Hardware section (also accessible in system_profiler SPHardwareDataType), or the Controller item within that section (or system_profiler SPiBridgeDataType).

Intel Macs without a T2 chip don’t report anything for their Controller, but those with T2 or Apple silicon chips reveal that they have a T2 or give an iBoot firmware version there. All three types of Mac also give a System Firmware Version in the Hardware overview.

This can get more confusing if you update or install macOS to an external disk. That will normally update the Mac’s firmware if the version of macOS installed on the external disk comes with more recent firmware. For example, if your Apple silicon Mac is currently running macOS Tahoe 26.3.1, it should have an iBoot firmware version of 13822.81.10. If you were to install Tahoe 26.4 to an external disk, as that has a more recent version of iBoot firmware, that should update the version installed in your Mac, and that remains so even when you start it up from its internal SSD.

As far as I can tell at present, this can result in internally inconsistent reporting. When running 26.3.1 from its internal SSD, that Mac will report its old iBoot version in the Controller section, but its new mBoot version in the Hardware section. Although that could change by 26.4 release, it might remain in all older versions, so providing lasting confusion.

As Apple hasn’t documented this change, I don’t know whether this will apply to all Apple silicon Macs updated to macOS 26.4, or to those updated to the matching versions of Sequoia or Sonoma. Therefore this new version of SilentKnight doesn’t attempt to check these new mBoot versions, and merely reports those found as well as it can. Once I know more, I will endeavour to interpret the results.

SilentKnight version 2.14 for macOS 11.5 and later is now available from here: silentknight214
from Downloads above, from its Product Page, and via its auto-update mechanism.

Please let me know how you get on with these new firmware version numbers.

Note: version 2.14 now fixes a bug that failed to recognise T2 Macs correctly in certain localisations including German. Thanks to Jan for reporting this so promptly.