How I Run Claude Code Day to Day: tmux, Permission Modes and My Phone

Claude Code is Anthropic’s coding agent. It runs the same Claude models as the Claude app, but on your own machine, where it can read your files, run shell commands and change your code, and it comes with the paid Claude plans. I use it in a terminal rather than the VS Code extension or the desktop app: five sessions inside one tmux session on my laptop, nearly all started with permission prompts switched off, and reachable from my phone through the Claude app’s Remote Control, over SSH, or through a chat bot.

What follows is that setup in detail, with numbers from my own machine rather than from memory: the settings files, the session transcripts Claude Code keeps under ~/.claude/projects (mine go back to 28 August), and its prompt history, which goes back to February and holds 7,323 prompts.

Claude and Claude Code are different things

#

Claude is the family of models, and the chat app at claude.ai, on the desktop and on your phone, where you talk to them. Claude Code is an agent built on those models. You start it in a project folder and it works there in a loop, reading files, running commands, editing code and running the tests, until the job is done or it needs you. Ask Claude how to fix something and you get an answer. Ask Claude Code and you get the fix, and a diff to read.

I use both. Since 18 October a marketplace and community app I build has sent its translations straight to the Claude API from its Django backend, and the change that switched it over was made in a Claude Code session. In my transcripts, 94% of the replies came from Opus 5.5, and my settings have the effort level at high.

The native installer is one line and keeps itself up to date:

curl -fsSL https://claude.ai/install.sh | bash

It leaves a claude symlink in ~/.local/bin pointing into ~/.local/share/claude/versions/; mine moved from 2.1.305 to 2.1.306 on its own on 21 October. Claude Code needs a paid Claude plan (Pro, Max, Team or Enterprise) or an API account. Prices change often enough that I’ll leave them to Anthropic’s pricing page.

One tmux session, seven windows

#

As I write this, tmux list-panes -a shows one session on my laptop, main, with seven windows. Five are Claude Code, one per project: my marketplace app and my estimating app (both described in my current stack), this blog and two smaller things. My terminal profile opens every window with a login shell that attaches to main, so a new tab on the laptop and an SSH login from my phone land on the same sessions.

I tried another multiplexer from 17 September to 8 October and went back to tmux for a practical reason: the SSH app on my phone multiplexes with tmux, and its shortcut buttons send tmux’s stock keys. Lines like these in ~/.tmux.conf exist for the phone:

set -g prefix C-a                 # Ctrl-a prefix
set -g prefix2 C-b                # stock Ctrl-b too, for apps that send it

# Size each window to the client that used it last, not the smallest one,
# so a phone attached to the same session doesn't shrink it.
setw -g window-size latest

# Copy to the clipboard of whichever terminal is attached (OSC 52),
# so over SSH it lands on the phone's clipboard too.
set -g set-clipboard on

Inside tmux, two things change. Claude Code moves a running command to the background with Ctrl+B, which is now my second tmux prefix, so ~/.claude/keybindings.json switches it off and uses Meta+B instead:

{
  "bindings": [
    { "context": "Global", "bindings": { "ctrl+b": null } },
    { "context": "Task", "bindings": { "ctrl+b": null, "meta+b": "task:background" } }
  ]
}

The other is new lines. Enter sends the prompt. The docs give \ then Enter, and Ctrl+J, as the two that work in any terminal; Option+Enter works once the terminal sends Option as Meta; and Shift+Enter works natively in some terminals, but tmux only passes it through with extended-keys switched on. Mine isn’t, so in my sessions Shift+Enter sends the prompt. I rarely need any of them: 84 of my 7,323 prompts contain a line break I typed, while 279 contain a paste, which Claude Code folds into a placeholder like [Pasted text #1 +34 lines] and sends in full.

Terminal, VS Code extension or desktop app?

#

The same agent comes in several wrappers, and they read the same settings files. Going by the entry point Claude Code records in each transcript, this is how my sessions split:

For me it’s the terminal, and not out of loyalty. tmux, which my phone attaches to, needs one, and so do channels, which push outside events into a session and which the docs list as a CLI feature.

People also ask whether Claude Code needs git. The CLI doesn’t: my home directory isn’t a repository, and 208 of my prompts went to sessions started there. The desktop app’s documentation says git is required for its session isolation, where each session gets its own worktree, and pulling a cloud session into the terminal needs a checkout of the same repository. I’ve never seen the “Git is required for local sessions” message myself. My last desktop session, on 20 October, ran in a folder that isn’t a repository at all.

Permission modes, and the one I actually use

#

The permission mode decides how often Claude Code stops to ask, and Shift+Tab cycles through the modes. Manual (default) asks before most actions that edit files, run commands or reach the network. acceptEdits lets file edits and common filesystem commands through. plan reads and proposes without editing. auto has a second model, a classifier, block the risky actions instead of asking you. bypassPermissions asks about almost nothing. Since version 2.1.283, a terminal session starts in auto mode unless you say otherwise.

So my honest answer to “how do I run Claude Code without it asking for permission” is that I start it like this:

claude --dangerously-skip-permissions

62 of the 69 claude commands in my shell history carry that flag, and so do all five sessions running now. Of the 1,266 prompts I typed between 28 August and 21 October, 1,179 went to sessions in bypass mode, 82 to auto mode and five to Manual or accept-edits.

The docs are plain that bypass mode is meant for “isolated environments like containers, VMs, or dev containers without internet access, where Claude Code cannot damage your host system.” My laptop is none of those, and my settings record that I’ve clicked through that warning ("skipDangerousModePermissionPrompt": true). If you do the same, know that allow rules have no effect in bypass mode, so in my everyday sessions the 378 allow rules spread over 19 settings files do nothing at all. Deny and ask rules do still apply, and I have none of either.

The exception is the session that reads other people’s words. Its launcher doesn’t pass the flag, so it starts in auto mode. All 27 production events and 42 of the 43 chat messages that reached a session between 12 and 20 October arrived in auto mode, and none in bypass.

What actually keeps bypass mode from biting me is a few habits, written into Claude’s memory after they went wrong. On 10 September, with several sessions working in the same checkout of the marketplace app, a one-line fix survived four failed builds and then vanished before it was committed: another session had written over the file, and git had no record of it. The same day a deploy nearly shipped one session’s uncommitted work, because the deploy script builds the working tree, not HEAD. The rules since then: commit a small fix the moment it works, stage files by name and never with git add -A, look at git status for changes you didn’t make, and when main holds other sessions’ undeployed work, deploy from a worktree at the commit that’s live.

Reaching it from my phone

#

There are three ways in, and each one reaches something different.

Remote Control connects the Claude app on a phone, or claude.ai/code in a browser, to a session that keeps running on the laptop, files, tools and MCP servers included. I typed /rc 26 times between 13 September and 20 October. Now remoteControlAtStartup is on and new sessions connect by themselves: since the start of October, 67 of the 77 sessions I started had a Remote Control link, against 3 of 52 in the second half of September. With agentPushNotifEnabled on, Claude can send a push notification when it decides one is needed, which the docs say is usually when a long task finishes or it needs a decision. It needs a claude.ai subscription rather than an API key, and because the session runs on the laptop, the laptop has to be awake. Since 15 October mine doesn’t sleep with the lid shut (sudo pmset -a disablesleep 1).

It works the other way too. /teleport, or claude --teleport, pulls a cloud session that was started on the web or in the app down into the terminal, with its branch and its conversation. I’ve done that twice, both times in July.

SSH is for when I want the terminal itself. The phone reaches the laptop over the private network from my private-network post, and an alias attaches it to main, so I can swipe between the windows I left on the laptop. Getting the Mac to answer phone apps properly took four separate fixes, and the one that matters for Claude Code is that tmux must never start by itself: an app that opened a session to run docker ps got 72 KB of screen redraw back instead.

The chat bot is for the session I don’t want to sit and watch. Since 12 October one session has run with a small channel I wrote, which checks the app’s server once a minute for new production errors and project-board activity and hands them to the session, plus one of the official chat plugins, so the two of us on its allowlist can message it. The launch line looks like this, with the names made generic:

exec claude \
  --channels plugin:<chat-plugin>@claude-plugins-official \
  --dangerously-load-development-channels server:my-events "$@"

A supervisor script keeps it running inside tmux. After a restart it resumes the same conversation, so the session carries on rather than waking up blank, and it announces every restart in the chat. The session fixes things in the working tree and stops there, with one exception I added on 13 October: a bug that is actually hurting users in production it may fix, test, commit and deploy, and then tell us what it did.

Skills, memory and /goal

#

There’s no hooks key in any of my settings files. The nearest thing is /goal, which I’ve used 279 times since 11 July. It takes a condition and sets up a Stop hook for the session that, in Claude Code’s words, “will block stopping until the condition holds”. My goals read the way I’d say them out loud. A real one from July, typos and all, told it the build was “still broken, try a deeper fix and dont stop until” it was out to testers. To check on a long run without derailing it there’s /btw, a side question that stays out of the conversation. Mine are mostly some version of “hows it going?”.

Skills hold the things I’d otherwise explain every time. One user-level skill reads a weekly keyword report for the sites I look after, this blog among them, and applies it to titles, descriptions and tags. The questions this post answers came from its report for this blog, dated 18 October, and the skill file is versioned in a repo alongside its code. The marketplace app’s repo has its own skills: one starts the API in Docker and runs a smoke test, one works the project board, and one files the company’s expenses. The two plugins I have installed are a Swift language-server plugin and the chat one.

Memory is where the lessons go. I have 160 memory files across 17 projects, 83 of them for the marketplace app, and many are about something that broke. The app’s CLAUDE.md is now about six times as long as it was in June. This blog’s CLAUDE.md is an empty file; how a post should sound lives in a memory file instead.

For bigger jobs Claude starts subagents, 120 times in my main sessions, 40 of them forks of the conversation. That’s how this blog gets its Japanese, Korean, Chinese and Vietnamese versions. On 19 and 20 October a redesign of the app’s community section went through the Workflow tool four times: an audit through seven lenses and a critic, which confirmed about 58 findings; fixes by five groups that each owned their own files and were each reviewed; a pass for the leftovers; and an independent check that every finding had been fixed. It shipped on the 20th.

Where devbox comes in

#

My private-network post is about putting the heavy work on devbox, the office workstation with the GPU, and reaching it from anywhere. Claude Code does most of that reaching. Between 24 September and 19 October, 21 sessions on the laptop ran 1,470 commands on devbox over plain ssh: kubectl into the cluster that runs there, psql inside a database pod, tmux capture-pane to see how a long job was getting on. Because ssh devbox falls back to a tunnel off the office network, the same session works from the office, from home or from a café. And since the laptop no longer sleeps, a session can keep driving devbox while I look in on it from the phone.

Claude Code or Codex?

#

I can’t tell you from my own use whether Claude Code is better than Codex, and the table shows why:

Four threads in one week, on an image question, two changes to a website and a 3D scene, is a trial, not a comparison. One detail from them applies to any switch between agents. The 3D project kept its rules in a claude.md, and my first question to Codex there was whether it read Claude’s files before a conversation. It said it didn’t, and it only picked up the project’s rules when I asked it to read that file. Whichever agent you move to, the instructions file stays behind unless you bring it. I haven’t opened a Codex thread since. The extension loaded in VS Code on a handful of days between 24 September and 4 October without my starting one, and it’s uninstalled now.

So the verdict I can stand behind is narrow. Claude Code is what my setup is built around, and I haven’t gone back to see how Codex handles the same things today.

One last number says more about how I use it than anything above. In the main sessions on my laptop since late August, Claude Code ran 18,311 shell commands and read, wrote or edited a file 2,331 times. By count, most of its work is running the commands I’d otherwise be typing, on the laptop and over SSH, from wherever I happen to be. When it does write the code, that code isn’t welcome everywhere, which is a story of its own in the pyhtml2text post.