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 expected my first internship to be baptism by fire. As the most junior doctor to two teams of neurosurgeons, I knew I’d learn plenty of new skills, among them performing lumbar punctures. Within the first few days I had been guided through that, and for much of the next six months I averaged one every couple of days. In the 45 years since I completed that job, I haven’t performed another lumbar puncture, ventricular tap, tracheostomy, or any of the other techniques I had learned. I suppose if it was a matter or life or death, I could just about remember how to drill a burr hole in an emergency, but all those other skills have now faded, some in a matter of months.

Skill fade is a distinctively animal trait, and a function of our brain. It comes in degrees: the slight fade you get from a good vacation is quickly overcome once you’ve got your feet back under the desk; more noticeable amounts from a longer maternity or sickness absence might merit a couple of weeks ‘returning to work’; and after a year or two you’ll probably need a period of formal retraining.

For the last year or so there have been increasing concerns raised over the effects of AI on critical thinking, and the Harvard Gazette published an interesting range of opinions last November. There has been extensive discussion about the dangers of ‘cognitive atrophy’ and impairment of critical thought, but less about longer-term skill fade.

I write code because I enjoy doing so. I’m not good at coding by any means, but over the forty years that I’ve been learning to code I have had a great deal of pleasure. It’s a creative act, like painting, involving a rich range of cognitive skills including plenty of art. At the end you have created something of substance, that might also benefit others.

So when someone comes along and advises me to start using Claude or another AI to write code for me, I can’t understand why I might want to stop coding and learn how to brief something else to steal my pleasure, any more than I might ask an AI to make me a painting. Moreover, were I to hand over one of my pleasures in life to AI, I know I’d find it progressively harder to code myself. While I might grow increasingly skilled at getting the AI to do much of the work, I’d also become increasingly dependent on its coding skills rather than mine.

At my age, that would remove one of my defences against the onset of dementia, and free up time to go painting more often. But what would it mean to a young engineer at the start of what they intend to be a bright career? At a time when their skills should only be developing, they’d be letting them fade. And who is going to have skills to transfer when they teach the next generation?

This extends beyond coding. Many of us are handing our writing to AI for it to summarise, one of its undisputed strengths. I started learning to write summaries before I turned 11, and have continued to develop and refine those skills for 60 years. If you’re only 20 now and leave this task to your favourite AI, how long before your summarising skills fade away?

Of course the vendors of AI want your dependence on their products. For a modest $200 to $3,600 a year you can abandon most of your independent skills to Claude, ChatGPT or Grok. If that was investing in further development of your skills, I could see the sense in that. While there are plenty of substitutes for cognitive challenges and critical thought you’re getting AI to do, there’s no substitute for developing and maintaining your essential professional skills.

I’m not advocating that you should avoid AI altogether; there are times when it has its uses, and skilful use of any tool can always be turned to advantage. But if you write code, summaries or whole novels, you need to retain and develop your own skills alongside that. Like morphine, AI has great powers, but overused it can so readily become both addictive and destructive.