A Claude Code research workstation

This guide describes one way to set up a research workstation around Claude Code, the command-line agent Anthropic ships for software and writing tasks. It is written for tenure-track and tenured researchers at universities — people who are productive in their field, comfortable installing software, and curious about whether an agent-based workflow can absorb the mechanical scaffolding around research: bibliography work, formatting, repetitive structural edits, website upkeep, referee reports.

Nothing here is exotic. A Mac, a few free tools, a GitHub account. The goal is to describe the moving parts well enough that you can replicate the setup in an afternoon.

1.Hardware and core concepts

1.1Why a Mac Studio

Most research workflows today involve some combination of: parsing large datasets, running econometric or statistical models, compiling LaTeX, reading PDFs, and — now — running one or more AI coding assistants in parallel. The Mac Studio sits in a useful spot in the lineup: more performance and memory than a MacBook Pro, far less hassle than a Linux tower, and quiet enough to sit on a desk in a shared office without anyone noticing it.

A reasonable configuration:

• Mac Studio with an M-series Max or Ultra chip
• At least 64 GB of unified memory; 128 GB if you work regularly with large dataframes or experiment with local models
• 2 TB internal SSD as a baseline; an external NVMe drive over Thunderbolt 4 for cold storage

The chip generation matters less than the memory configuration. The bottleneck in modern research computing is almost always memory, not compute. A model that fits in RAM runs fast; one that does not, no matter how powerful the CPU, runs at the speed of swap.

1.2Why memory matters for concurrent work

The setup described in this guide assumes you can have several Claude Code sessions running at once — one editing a paper, one running a long script, one fetching a citation from the web, one helping you write a referee report. Each session occupies roughly half a gigabyte to two gigabytes of memory depending on what it is doing.

Add the everyday tail: a browser with two dozen tabs (the working memory of any active researcher), a PDF reader holding the papers you are currently citing, a statistical package with a panel loaded, a LaTeX editor, Zotero or another reference manager. The total adds up quickly.

With 64 GB you can comfortably run four to six concurrent agent sessions plus the usual stack. With 128 GB the question goes away entirely; you stop noticing memory and run as many sessions as the work needs. This single decision — spending more on RAM than feels reasonable at the moment of purchase — is the highest-return part of the setup.

1.3What Claude Code is

Claude Code is a command-line program, distributed by Anthropic, that exposes the Claude model as an interactive agent. You launch it in a terminal, inside a directory, and describe what you want done in plain English. It can read and edit files on your machine, run shell commands, browse the web, call external tools, and ask you questions when something is unclear.

It reads essentially every text-based format a researcher encounters: LaTeX and BibTeX, Markdown, HTML and CSS, Python and R and Julia and Stata, YAML configuration, JSON, CSV. It can read PDFs and images. The practical effect is that work which used to take the form of "I know what I want; let me remember the exact syntax" becomes "I describe what I want, and Claude Code does it while I read the next paper."

Several capabilities are worth flagging up front because they change what you can ask:

• It can run code. Not just write it. When you ask for a regression, it can write the script, run it, and read the output to verify it worked.
• It can iterate. If the LaTeX build fails, it can read the error log and try again, the way you would.
• It has persistent project context. A short Markdown file called CLAUDE.md in any project directory acts as standing instructions for every session in that directory.

1.4What a terminal is

A terminal is a text interface to your computer. You type a command, the computer runs it, the output prints back. macOS ships with one called Terminal.app; iTerm2 and Ghostty are popular third-party alternatives with better defaults for serious use.

Inside the terminal runs a shell — the program that interprets what you type. The default shell on macOS is zsh. You will spend more time in the terminal than you might expect, because Claude Code lives there, and because almost every research tool (LaTeX, git, R, Python, data downloads) is easier to drive with a few short commands than through a graphical interface.

If you have never used one, the moves to know are these: cd changes directory, ls lists files, open . opens the current folder in Finder. That is enough to begin.

2.Environment and remote access

2.1Installing Claude Code

Open Terminal.app and install Claude Code with the official script:

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

If you already have Node.js installed (most researchers eventually do; it ships with Homebrew), the npm route works equally well:

$ npm install -g @anthropic-ai/claude-code

Then authenticate by running claude for the first time:

$ claude

A browser window opens, you sign into your Anthropic account, and the session inherits your subscription. From then on, typing claude in any directory drops you into an interactive session scoped to that directory. The directory becomes the working context: Claude Code reads, edits, and runs commands relative to it.

You can also run a one-shot, non-interactive query:

$ claude -p "summarize the methodology section of paper.tex in three sentences"

A good first step in any new project is to drop a short CLAUDE.md file in the project root. Two or three paragraphs are enough: where the data live, how files are named, what conventions to follow, anything to avoid. Claude Code reads this before every session in that directory.

2.2Remote access with Tailscale

The Mac Studio sits on a desk somewhere. You will want to reach it from a laptop in a coffee shop, an iPhone in a seminar, or an iPad while travelling. Tailscale is a peer-to-peer mesh VPN that gives every device you own a stable private IP and a memorable DNS name (something like studio.tail-XXXX.ts.net). The personal plan is free for up to 100 devices.

Install on the Mac Studio:

$ brew install --cask tailscale

Open the Tailscale app from the menu bar, sign in (Google, Microsoft, or email), and the machine joins your "tailnet." Repeat the install on the iPhone (App Store), the iPad, and any laptop you use. All devices logged into the same account see each other automatically, with no port-forwarding, no static IPs, and no exposed services on the public internet.

Two flavours of remote access then become available:

SSH from a phone or laptop. On the Mac Studio, enable Remote Login in System Settings → General → Sharing → Remote Login. On the iPhone, install a terminal client — Termius works well on a free tier, Blink Shell is excellent if you are willing to pay for it. Add a host pointing at the studio's Tailscale name. Connecting opens a shell on the studio:

phone$ ssh you@studio

Once connected, attaching to a tmux session (next section) gives you the exact terminal that is open on the studio's monitor at home. You can edit a paper from a phone if you must.

Full desktop access for moments when you genuinely need the GUI — a Stata viewer, a Mathematica notebook, a finicky PDF annotation tool. Enable Screen Sharing in the same Sharing pane. From a Mac on the tailnet, Finder → Go → Connect to Server → vnc://studio. From an iPad, an app such as Jump Desktop or Screens speaks VNC over Tailscale and behaves well on LTE.

2.3Persistent sessions with tmux

A bare SSH session dies the instant the connection drops. Walk into a basement seminar room, lose your signal, watch your half-finished thought disappear. tmux solves this. It runs a long-lived server on the Mac Studio that owns your shell sessions; when you connect from any device, you attach to a running session and resume exactly where you were.

Install:

$ brew install tmux

Start a named session for a project:

$ tmux new -s paper-1

Inside the session, do whatever you would normally do — launch Claude Code, start a long Python job, edit a .tex file. To detach without killing anything:

Ctrl-b d

The session keeps running on the studio after you disconnect. Later, from any device on the tailnet:

$ ssh you@studio
$ tmux attach -t paper-1

You are back where you were — scrollback, running commands, open editor and all. List all sessions with tmux ls. Create multiple panes inside one session with Ctrl-b " (horizontal split) and Ctrl-b % (vertical split); switch with Ctrl-b followed by an arrow key.

A common layout: one pane running Claude Code on a paper, one pane running a long data job that prints progress, one pane for ad-hoc shell commands. A reasonable starting point for ~/.tmux.conf:

# ~/.tmux.conf
set -g mouse on
set -g history-limit 50000
set -g default-terminal "screen-256color"
set -g status-bg black
set -g status-fg green
set -g base-index 1
setw -g pane-base-index 1
bind | split-window -h
bind - split-window -v

3.Website and GitHub integration

3.1Your homepage as a repository

Most academics maintain a personal site: a CV, a list of papers, a research statement, teaching materials. The simplest robust setup is a GitHub Pages site backed by a public repository named yourusername.github.io. The site is served at https://yourusername.github.io — and at any custom domain you choose to point at it — with no server to maintain, no host to pay, no admin panel to log into.

Two paths work well, depending on temperament:

• Plain HTML and CSS. Hand-write index.html. Total control, very fast load times, easy for Claude Code to edit, never breaks.
• A static-site generator such as Quarto, Hugo with the academic theme, or Jekyll with the al-folio template. More built-in features (publication lists, posts, talks), more moving parts that occasionally need maintenance.

Plain HTML if you want the site to function unchanged in ten years and to never think about it again; a static-site generator if you intend to post regularly and want the formatting handled for you. Most researchers are better served by the plain-HTML route than they expect.

Initial setup, in either case:

$ brew install gh
$ gh auth login

$ mkdir -p ~/research/website
$ cd ~/research/website
$ git init
$ gh repo create yourusername.github.io --public --source=. --remote=origin

Then create or generate the site files, commit, push:

$ git add .
$ git commit -m "Initial site"
$ git push -u origin main

GitHub Pages serves the site within a minute or two of the push. From this point on, the site lives in a folder on your Mac, version-controlled, editable by anything that can edit text files — including Claude Code.

3.2LaTeX and HTML with Claude Code

The reason this whole setup pays off is that the same agent edits both your papers and your website with the same conventions. Two file types do the bulk of the work.

LaTeX. Claude Code reads .tex and .bib files natively. You can ask it to rewrite a paragraph in a methodology section, regenerate a results table from an updated estimate, reorder citations, swap a reference style across the whole bibliography, or build the paper end-to-end:

$ cd ~/research/paper-1
$ claude
> add a robustness check using the alternative
  specification we discussed earlier, regenerate
  the relevant tables, and rebuild the PDF

What happens then is that it edits main.tex, possibly creates a new sections/robustness.tex, runs the appropriate script to regenerate tables, runs latexmk -pdf main.tex, watches the log for errors, and iterates until the PDF builds cleanly. You read the result and accept, reject, or revise.

HTML and Markdown. For the website, the equivalent prompt is:

$ cd ~/research/website
$ claude
> add the working paper described in
  ~/research/paper-1/abstract.txt to the
  publications list on the homepage, then
  commit and push

It edits the right file, generates the right HTML or front-matter, and (if you want) commits and pushes the change in one step. The site updates within a minute.

Because the repository lives in the file system and uses git for version control, every edit is reversible. You never paste content into a CMS, never click through a hosting dashboard, never lose work because a session logged out. git diff and git log tell you exactly what changed and when.

3.3Why this is worth maintaining

A homepage that is automated this way has a few practical advantages over the typical hosted alternative.

• Updates take seconds. The friction that keeps most academic homepages a year or two out of date disappears. A new working paper takes one prompt and one push.
• The local copy is canonical. The master is your git repository. If a hosting provider disappears tomorrow, your site survives intact and you can point it elsewhere in an afternoon.
• The tool that drafts the paper also publishes it. The same Claude Code session that finalizes a working paper can update the homepage and your CV PDF to reflect it. There is no separate "publication chore."
• Everything is text. Every change can be reviewed in git diff. Every prior version is recoverable. There is no opaque binary state.

4.Research workflow and data

4.1Folder organization

A consistent folder layout pays for itself the first time you return to a project after a year away from it. The pattern below works for most quantitative empirical projects; adapt names to your field but keep the structure:

~/research/
  project-name/
    paper/
      main.tex
      sections/
      figures/
      tables/
      refs.bib
    data/
      raw/          # never overwrite anything in here
      derived/      # outputs of cleaning scripts
      external/     # data fetched from outside sources
    code/
      01_clean.py
      02_analysis.py
      03_tables.py
      utils/
    notes/
      decisions.md  # short log of why you chose specifications
      todo.md
    submissions/
      journal-1/
      journal-2/
    CLAUDE.md       # standing instructions for Claude Code
    README.md

Two principles do most of the work:

• raw/ is immutable. Cleaning scripts read from raw/ and write to derived/. You can always rebuild derived/ from scratch; you can never recover raw/ if you overwrote it.
• Code files are numbered. A new collaborator — or future you, after a year — reproduces the analysis by running them in order. Numbered names also reveal at a glance which files matter and which are scratch.

A CLAUDE.md at the project root might read: "Use data/derived/panel.parquet as the primary dataset. All figures go to paper/figures/. Tables are generated by code/03_tables.py and pulled into paper/main.tex via \input{}. Never modify anything in data/raw/."

4.2Downloading and saving data

Most data acquisition collapses into one of three patterns. Claude Code can drive all three.

Direct download. For datasets behind a stable URL:

$ cd ~/research/project-name/data/external
$ curl -O https://example.org/dataset.csv

When the source is a portal that requires logging in or clicking through, you can still automate it: Claude Code can drive a headless browser, fill the form, follow the link, and save the file in the right place. The trick is to describe what you want in the same way you would describe it to a person doing the click-through — "go to the data page, choose 2010 to 2024, download the CSV."

API-backed. For data that lives behind an API — a national statistics office, a financial vendor, an internal data warehouse — write a small script in code/ that fetches and caches the data into data/external/. The cache is the unit of reproducibility. Commit the cached file (subject to licence and data-sharing rules), not just the script. Future you and your coauthors should be able to rebuild every derived file from data/external/ plus code/.

Cloud-synced services. When data arrives via Box, Dropbox, OneDrive, SharePoint, or an institutional file share, mount the service as a folder (the macOS clients all do this) and symlink it into the project:

$ ln -s "/Users/you/Library/CloudStorage/Box-Box/project-name" \
       ~/research/project-name/data/box

Whichever pattern you use, the rule is: write down where the data came from. A one-line entry in a sibling README.md — source URL, date downloaded, the script or API call used — is the difference between a project that is reproducible in five years and one that is not. Claude Code can maintain this log for you as a side effect of every download.

4.3Referee reports and other writing

The same setup handles the writing tasks that surround the research itself.

Drafting referee reports. Save the manuscript PDF and the cover letter into ~/research/refereeing/journal-name/manuscript-id/. Launch Claude Code there and ask it to read the paper, identify the main contribution, summarize the methodology, and draft a structured report in the journal's preferred format (most journals prefer a short summary, then strengths, then concerns, then minor comments). You then rewrite the parts that need your taste and judgment — but the mechanical scaffolding of the report drops from hours to minutes, and the time is spent where it actually adds value.

Responses to referees. When revising your own paper, place the referee report and the current draft in the same directory. Claude Code can draft a point-by-point response, cross-reference each comment with the specific section of your revised paper, and produce both a response letter and a changelog of edits. You revise; the structure is already there.

Reading and literature reviews. Drop PDFs of related papers into a folder. Ask Claude Code to extract bibliographic information into BibTeX entries, generate one-paragraph summaries of each paper, group them by theme, and draft a literature-review section organized accordingly.

Teaching materials. Slides (LaTeX Beamer or Markdown-based tools such as Marp), problem sets (LaTeX), exams, syllabi — all of these are text files inside a teaching/course-name/ folder. The same edit-via-Claude-Code workflow used for papers applies. Updating a syllabus from one term to the next becomes a single prompt.

The common thread is that the unit of work is a folder of files, version-controlled by git, edited by an agent that understands every format in it. The setup pays off most on the boring scaffolding — bibliographies, formatting, repetitive structural edits, file organization, response letters — which is precisely the work that most often slows research down.

5.Appendix: one-time setup

A condensed checklist of what to install on a fresh Mac Studio, in order. Each step is a single command in Terminal.app.

# Homebrew (package manager)
$ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Core tools
$ brew install --cask tailscale iterm2
$ brew install tmux git gh node

# Claude Code
$ curl -fsSL https://claude.ai/install.sh | bash

# LaTeX (full distribution)
$ brew install --cask mactex-no-gui

# Python tooling (one common choice)
$ brew install uv

# Sign into Tailscale on this Mac and on every phone, tablet, and laptop.
# Enable Remote Login and Screen Sharing:
#   System Settings → General → Sharing → Remote Login
#   System Settings → General → Sharing → Screen Sharing

# Set up the research workspace
$ mkdir -p ~/research
$ cd ~/research
$ tmux new -s main
$ claude

A reasonable first session, after all of the above, is to open a tmux window, run claude in ~/research/website, and ask it to scaffold a homepage. By the time it is done, you will have decided whether this workflow fits the way you actually work.