The command I've typed a thousand times

I was running a TypeScript typecheck against a submodule, npx tsc --noEmit inside projects/secureclear/web, to confirm a change hadn't broken anything. Before that, I did what I always do when I want to run something in a different folder: I ran cd into it, on its own line, then went to run the command.

I've done that move so many times it isn't a decision anymore. It's muscle memory. Submodule or not, folder or not, cd first, then whatever comes next.

The trouble

The typecheck never ran. The next tool call failed. So did the one after that, and every one after that, for the rest of the session. Same failure, every time: EPERM. Every tool was bricked, not just the one that had touched the submodule.

There was no recovering it. Not "restart the tool and it's fine," not "back out and re-run." The session was done. Everything downstream of that one cd was dead weight until I closed it and started over.

The false trail

My first instinct was that something was wrong with the submodule itself. Bad checkout, weird permissions, something specific to that repo. That's the comfortable explanation, because it means the fix is local to that one folder and I can move on.

It wasn't that. The specific submodule didn't matter. The problem wasn't the destination. It was the command itself, alone on its own line.

The turn

A standalone cd into a submodule doesn't just move you into a new directory. It invalidates the shell's working directory for the session. The shell no longer has a working directory it can trust, and every tool call that follows depends on that context existing. Once it's gone, nothing after it has anywhere to run from. Not a bug in the destination. A property of doing it as a bare, unchained command.

The fix is boring, which is usually a sign it's correct: never issue a standalone cd into a submodule. Chain it into the same line as whatever you're actually trying to do (cd path && command), or skip cd entirely and use an absolute path. Either way, the working directory never gets handed off in a way the session can't recover from.

What I actually changed

The habit was the problem, not the tool. I'd built years of reflex around cd being a free, reversible action. It costs nothing in a normal terminal where I'm the one typing the next line by hand and I'd notice immediately if something felt off. In an agent session, there's no equivalent instinct watching over my shoulder. The command runs, the damage is already done, and nothing tells you until the next tool call throws EPERM and you're staring at a dead session with no way back.

That's the real lesson here, and it's not "watch out for submodules." It's that the shortcuts I trust because they're small and familiar are exactly the ones I never think to question when I hand the keyboard to something else. A cd on its own line felt like nothing. It ended the session anyway.

I don't run bare cd into a submodule anymore, chained or not, without thinking about it first. That's a small rule, but it came from losing an entire session to a command I'd have called harmless an hour earlier.

The question

What's the command in your own workflow that you trust so completely you've stopped noticing you're running it?

We build agentic systems that prove their work.

If you are shipping work an AI agent produced, book a scoping call. We will walk through where a passing test stops meaning the result is right, and how to verify the difference before it reaches a customer.

Book a scoping call

Sources

  1. First-party account: during a SecureClear session, npx tsc --noEmit ran inside projects/secureclear/web (a submodule); the bare cd that preceded it invalidated the shell's working directory, and every subsequent tool call failed with EPERM for the rest of the session, unrecoverable