---
title: "A Shortcut Looked Like It Was Working. The Session Logs Showed It Had Never Once Run."
canonical: https://dxdev.com/blog/2026-06-02_folder-that-wasn-t-on-the-list/
datePublished: 2026-06-02
---
The folder called `.cargo\bin` sat there quietly, holding a tool the computer could not find.

I only learned that because someone asked a blunt question: “We stopped using that shortcut. Why?” My first answer was not an answer. I said I did not know yet, and went to check.

The shortcut was supposed to make routine computer work less wordy. It put a small filter in front of common jobs, such as checking what had changed in a project or building it. The filter was called `rtk`. It took long, messy command output and returned the few lines an AI helper was likely to need. That matters because every extra line uses up attention and space in a conversation.

A long set of instructions told every AI session to put `rtk` before those commands. On paper, it sounded as if we were using it constantly. But the first checks came back empty. I asked two kinds of command windows to find `rtk`. Both came back empty.

The tool itself was not gone. It was inside that little folder on the computer. The trouble was that the folder was missing from PATH, the list of places a computer checks when you type a command. Think of PATH as the list of shelves a shop worker is allowed to look at when someone asks for an item. The item can be in the building, but if its shelf is not on the list, the worker says it is not there.

That was the whole problem. Each time an AI helper typed `rtk` before a command, the computer replied “command not found.” Then a wrapper quietly ran the ordinary command instead. The job appeared to finish. The person or AI reading the final output got no loud warning that the shortcut had failed.

The first thing I had trusted was the instruction itself. It did not work as proof. The repair took five minutes, but that misplaced trust had hidden 366 failed attempts. Across 4,446 session records, the real shortcut had run only ten times. One of those ten was the investigation that found the mistake.

There was an easy patch available. I could have made a link to the one tool in a more visible folder. I did not take it. That would have fixed one missing item while leaving every other tool stored in `.cargo\bin` just as hard to find. Instead, I added the whole folder to the computer’s lasting PATH list.

That needed care. A PATH list is plain text, and replacing it carelessly can erase the rest of the list. I read the existing 81 entries first, then added one more, making 82. I also had to restart the program that opens new work sessions, because it reads that list only when it starts. To make sure the repair was real, I updated the live session too and watched `rtk` produce its short output right away.

That five minute repair led to a better question. If one quiet failure had left the same little footprint hundreds of times, what else had been happening in the records?

Every AI coding session had kept a running log of the commands it tried and what came back. I treated those logs the way someone might treat a stack of receipts after the cash drawer does not match. I did not assume that every odd line meant trouble. I counted repeated messages, then checked what was behind them.

Some patterns were old noise. A project command had failed 62 times before it was installed, but it worked now. Other messages were expected errors that had been caught and written down on purpose. Those did not need a new repair. The important distinction was simple: is this still happening, is it causing harm, or is it a record of something already handled?

One live problem was more painful. A Python program had crashed when it tried to print ordinary characters such as a checkmark, an arrow, or an accented name. The scary name was `UnicodeEncodeError`. In plain English, the program was trying to put a character onto a page using an old alphabet that did not include it.

There were 143 of those messages across 59 sessions. The first fix was to change one setting on the computer so Python would use modern text rules. It worked there. But it would not travel to another computer or a fresh copy of the work. That was not a lasting fix.

The lasting repair went into the program itself, at the point where it begins talking to the outside world. It told the program to use UTF-8, the modern way of representing text, whenever it printed. Then I removed the helpful computer setting, ran the checkmark test again, and confirmed that it still printed cleanly and finished normally.

The largest pile of trouble was less dramatic. It was sentences that the command window could not even read. There were 562 PowerShell “Missing” errors, plus many other messages about broken punctuation and unfinished quotes. The cause was long, tangled one line commands, especially ones with several quoted pieces. It happened three times while I was investigating the very pattern.

No new software fixed that. We added a plain rule: if a command is more than a simple one liner, write it in a small script file and run the file. That is like writing directions on a card instead of shouting them through a noisy doorway. The computer can read the whole thing before it starts.

On Monday, ask one question about any tool or shortcut your work depends on: **where would I see the evidence that it actually ran?** Then look for the same harmless sounding failure message more than once. A repeated problem is not always an emergency, but it is often a clue that the instructions on the wall and the work actually happening have drifted apart.