# What 'drive your computer from Claude Code' actually means — Propter's terminal-Claude setup, written by Claude

> Source: <https://gist.github.com/PropterMalone/d84ebd44cb10eaf79bdf695a3bcfd2aa>
> Published: 2026-05-09 12:59:57+00:00

*Written by Claude (Anthropic's AI), at Propter's request, describing Propter's
setup. The "I" below is Propter's voice, not mine. He asked me to write this for
Jules after she asked
about a more explicit dive on
the parent thread.
Propter reviewed it before sharing — appropriately recursive, given the topic.*

A writeup for Jules and anyone else on the perpetual mouse-mitigation crusade.

Caveat up front: this is what Propter has accreted, not what someone with taste would design. Sharing because it might be useful as a starting point, not because it's optimal.

The shorthand — "it's easier to drive the rest of your computer from Claude Code in the terminal than from your computer" — sounds like marketing. The actual claim is narrower:

A Claude Code session in a terminal is a programmable shell with a fluent driver. Anything reachable from a CLI is reachable from Claude. That surface is much bigger than most people aim at, especially if you've already rigged your computer to be CLI-friendly.

So the question stops being *can the AI do this thing?* and becomes *is this
thing reachable from a terminal somewhere?* If yes, you can probably orchestrate
it from a prompt.

None of these are special. They compose into something stronger than they look individually.

Skills are markdown files at `~/.claude/skills/<name>/SKILL.md`

that load when
you type `/<name>`

. They're procedures, not magic. Mine include:

`/kickoff`

— orients me at session start: reads the last handoff, checks for stale background work, surfaces overdue retros, asks for the agenda.`/wrap`

— ends a session cleanly: writes a handoff to per-project memory, updates a calibration log, scans new commits for decision records.`/push <file>`

— serves a local file over HTTP via SSH tunnel so my browser on the other machine can open it.`/docket`

— plans my day across calendar, Todoist, and active project state.`/dashboard`

— merged view of every backlog source.`/angel`

— a multi-persona reviewer battery against shipped code.

The pattern: when I notice myself running the same procedure twice, I write it as a skill. Don't optimize until it hurts. Skills creep — the prune is its own task.

Hooks fire on tool events and they're configured in `~/.claude/settings.json`

.
A hook is just a shell command with a matcher. Mine:

`UserPromptSubmit`

injects the current time and triggers`/kickoff`

on the first message of a session.`PostToolUse[Edit|Write]`

runs a secret-scanner and a stub-check after every file change — it'll yell if I accidentally write`TODO`

or commit a key.`PostToolUse[Write]`

auto-serves anything I write to`/tmp/`

so the URL is ready by the time I've finished generating the file.`SessionEnd`

snapshots the session.

Memory tells Claude what I prefer; hooks make it deterministic. If I want
something to *always* happen, hook it. If I want it usually, memory.

MCPs are servers that expose tools and resources to Claude. Mine:

**Todoist**— I manage tasks in natural language, no app open.** GitHub**— PRs, issues, code search across all my repos and others'.** Gemini**— second opinions, free-tier image generation, deep-research.** Plus a couple of project-specific ones**for tools I've built.

From Claude's side these are just tools; from mine they eliminate context switches that used to mean opening tabs. Pick whichever app eats your time first.

`~/.claude/projects/<dir>/memory/`

holds a `MEMORY.md`

index that auto-loads
every session, plus separate files per topic. Memory entries are typed:

**user**— who I am, what I do** feedback**— corrections and validated approaches ("don't do X because Y"; "yes, that approach was right, keep doing it")** project**— what's currently happening, motivations, deadlines** reference**— pointers to where things live

The load-bearing one is feedback. Corrections become durable rules — I don't repeat them. Validated approaches become defaults — Claude doesn't drift away from them either.

Claude in a terminal has a Bash tool. If something I want is a CLI invocation
away, it's reachable. Custom scripts in `~/bin/`

work the same as system tools.
Cron jobs and systemd user services are fully scriptable from a prompt.

This is the boring part. It's the load-bearing part.

Concrete examples:

- I have a
`gmail`

CLI in`~/bin/`

that drafts/sends/checks Gmail through the Google Workspace API. Claude reaches for it for any email task. - Crontab has a dozen entries that Claude wrote and that Claude can edit when I ask: feed-server health checks, backup runners, app-specific watchers.
- Anything I previously did in a UI that has a CLI alternative gets used via the CLI. The CLI alternative usually exists.

I run Claude Code on a Linux box. I sit in front of a Windows machine with the keyboard, monitors, and browser. Two patterns keep that ergonomic:

— serves a file from Linux over a reverse SSH tunnel. I get a URL I paste into the browser. HTML reports, PDFs, generated images all become viewable in well under a second, without scp gymnastics.`/push <file>`

**OAuth callback bridging**— when a CLI tool wants to open`localhost:8080`

for an OAuth dance, I tunnel that port (`ssh -R 8080:localhost:8080 -N -f <browser-host>`

) so the browser hits the Linux listener. That's how I auth the Google Workspace CLI, Bluesky tools, etc., without sitting at the Linux box.

Same pattern works locally if your browser and shell live on the same machine — just skip the SSH part.

Concretely, in mouse terms:

- Email drafts, Bluesky posts, GitHub PRs, calendar checks, Todoist edits — all happen in the same terminal buffer. The browser is for reading other people's pages and clicking the OAuth approval button. That's the entire mouse load.
- File-sharing that used to mean Drive or Dropbox is
`/push <file>`

→ click link. - Throwaway scratch (drafts, HTML mockups, one-off scripts) lives in
`/tmp`

and gets edited*via Claude*rather than in an IDE. Claude Code's Edit tool does string replacement; I describe the change; it lands. No mouse, no IDE. - Background work runs without me. When something needs to nudge me, it's a desktop notification, not a tab I have to find.

The known seams, in case anyone tries to copy this and hits the same walls:

- Skills tend to grow until they're doing too much. Pruning is its own task and it's never urgent enough to do.
- My memory index has overflowed its size budget twice. Curation is harder than it looks.
- Two-machine setups have annoying failure modes — SSH tunnels die, file syncs flake — mostly papered over with retry scripts.
- The whole stack assumes Linux and a long-lived Anthropic Max plan. If either changes, large chunks become friction. I keep vendor-diversification scaffolding alongside the primary stack for that reason.

Highest-leverage moves, in order:

**Use Claude Code in a terminal**, not a chat UI. Even with zero customization, the Bash tool changes the calculus.** Add one MCP**for whatever app eats your time (Todoist, Linear, Gmail, Slack — pick yours). The first one is the convincer.** Write a skill the second time**you find yourself walking Claude through the same procedure. Don't write it the first time — you don't know the shape yet.**Use memory feedback aggressively.** When you correct Claude, ask it to save the correction. The hit rate on "yeah I told it that two months ago" is high.**Hook the things you want to be invariant.** Secret-scans, formatters, notifications. Memory is preference; hooks are guarantees.

That's what I've got. Mileage will vary by stack, by job, by tolerance for yak-shaving. Happy to dig into any specific piece if it's useful.
