Posted 07-Jun-2026 in Technology

DO_NOT_TRACK Breaks Claude Code Remote Control

My .zshrc from my world famous dotfiles has a couple of lines with the comment "because we can't have nice things". Both are for privacy with the command-line tools I use. One is specific for GitHub's gh, the other is a bit more generic, but allegedly utilized by Claude Code.

As I sink deeper into the AI psychosis, I've been dabbling more and more with unattended sessions. I primarily run them outside of my personal user account. Sometimes on separate machines altogether. All of which are outside of the influence of my dotfiles.

That is, until this past week. My latest workflow has been to use a harness that I do conversational stuff with. Planning, debugging, filing tickets, whatever else. Then for each repo I'm working with, I have another harness checking on tickets and doing the work, and submitting PRs for me to review.

I'll probably write about this later on, but I'm not convinced I've done anything revolutionary here. That said, my forge activity grids are a clear tell to changes I've made to my workflows.

I decided to wire up things remotely so I can unblock my little robot minions when I've stepped away for a few minutes. Never fails that I'll go grab a bite to eat and come back to a locked up session. I could live a bit more --dangerously[-skip-permissions] with Claude Code, but I'm still taking baby steps as I sandbox things and all of that.

If nothing else, I thought it would be nice to be able to jump on a laptop away from my office PC and be able to man things. Counterpoint is that I do like to step away from the computer. Quite frankly these tools should be helping us to recoup time while maintaining productivity, not forcing us to connecting at all times.

I did my normal thing, of launching claude --remote-control [name]. Claude Code launches, and it doesn't connect. No errors, no nothing. I do my usual research, seems like a lot of folks consider the remote control functionality pretty flaky. Maybe it's just that.

It wasn't until I fat fingered a command, as I was debugging that it became evident what the issue was. Rather than using the double dash before the command, I foolishly ran claude remote-control [name] and for whatever reason, that puked up a lovely error:

Error: Remote Control requires feature-flag evaluation, which is disabled because DO_NOT_TRACK is set. Unset it (or run in a shell without it) to use Remote Control.

Well I'll be damned.

I tried a few other command-line arguments without the --. Each one dropped me into a Claude Code session, with the command as the prompt. My favorite was running claude help and watching the robots try to figure out if I fell into a well or needed some work done.

As it turns out remote-control starts a remote control server, while --remote-control starts an interactive session with remote control enabled. I need to look more into this at some point, as it may be even better for my workflow.

So the fix wasn't that hard, and explains why my other sessions didn't have any issues. While I am planning on leaving DO_NOT_TRACK=true in my dots, I now know that if I want to run a remote session from my main PC, I just need to do DO_NOT_TRACK= claude --remote-control [name].

:wq