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.

Most sections that follow share a structure: a short statement of why a tool exists, a side-by-side comparison of the old way (the workflow you would use without Claude Code) against the Claude Code way, a recommended video tutorial, and the concrete commands. The old version is included not as nostalgia — it is the workflow underneath. Knowing it makes the agent-driven version legible, and it is the version you fall back to when an agent is unavailable.

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. Section 5 covers how to configure this properly.

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. The pattern is the same with or without Claude Code; what changes is whether you operate it by hand or by description.

Direct download. For datasets behind a stable URL, the manual command is:

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

That command above is "the old way" — useful to know, and the fallback when no agent is available. The Claude Code version is to ask. When the source is a portal that requires logging in or clicking through, the manual route gets painful (browser dev tools, cookie copying, brittle scripts); the Claude Code version still works because the agent can drive a headless browser, fill the form, follow the link, and save the file in the right place. Describe it the way you would describe it to a person: "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.Configuring Claude Code properly

Claude Code rewards a small amount of one-time configuration. Five things matter: choosing the right subscription plan, understanding how the usage limits work, writing a CLAUDE.md file per project, letting the auto-memory system accumulate context across sessions, and installing reusable skills. This section covers each in roughly the order you will encounter them.

5.1Plans, budgets, and limits

Claude Code is included in Anthropic's Pro and Max subscriptions. The plan determines two things: how many tokens you can spend in any rolling five-hour window, and how many you can spend in a rolling week. Both are real ceilings — when you hit either, the agent pauses until that window resets.

A representative research session — drafting a referee report, editing a section, fetching and cleaning a small dataset — spends on the order of 10–30 thousand tokens. Pro lets you do one or two of these in a 5-hour window before pausing; Max 5× covers a full working morning of agentic work; Max 20× is the right tier once you routinely run three or four concurrent tmux panes with Claude Code in each.

The 5-hour window resets on a rolling basis from your first message in that window. The weekly cap is harder — it cannot be worked around by waiting for the next 5-hour bucket. The Max plans add a second weekly limit specifically for Opus, the more capable (and more expensive) model, separate from the all-models cap.

Recommendation for an active research workstation: Max 5× at minimum, Max 20× if you intend to run parallel sessions for hours at a time. Payment is via credit card through the Anthropic console; institutional invoicing and seat management are available on the Teams and Enterprise plans, which your university may already have a master agreement for — check with your research-computing office before paying out of pocket.

5.2CLAUDE.md per project

Every project directory should have a CLAUDE.md file at its root. Claude Code reads this file at the start of every session in that directory. It is the single highest-leverage configuration step — it eliminates the need to re-explain the same context every time you open a new session.

Generate a starter file with the built-in command:

$ cd ~/research/project-name
$ claude
> /init

What to put in it:

• File paths the agent should know about. Where the canonical dataset lives, where figures go, which file is the main paper.
• Conventions. Variable naming, table style, citation key format, language of comments.
• Things to avoid. "Never modify data/raw/." "Do not edit the journal submission folder — that is a frozen copy."
• Standing requests. "Always rebuild the PDF after edits." "Always run the test suite before committing."

A reasonable template:

# Project: working paper on X

## Stack and conventions
- Python via uv; canonical dataset: data/derived/panel.parquet
- LaTeX paper at paper/main.tex; figures from code/03_figures.py
- Bibliography: paper/refs.bib (BibTeX, keys: author_year)

## Rules
- Never modify data/raw/. Cleaning lives in code/01_clean.py.
- Tables generated by code/03_tables.py and \input{} into main.tex.
- After any edit to paper/, run `latexmk -pdf main.tex` and report
  whether the build was clean.
- Commit messages: "[scope] brief change" (e.g., "[paper] tighten intro")

The file is plain Markdown. Edit it as the project evolves. Two minutes spent updating CLAUDE.md when you change a convention saves hours of re-explaining it.

5.3Auto memory across sessions

Beyond CLAUDE.md, Claude Code maintains a file-based memory under ~/.claude/projects/<directory-hash>/memory/. Each "memory" is a small Markdown file with frontmatter. The agent writes these automatically when it learns something durable: a preference you stated, a correction you gave, a non-obvious fact about how this project is organized. When you start a new session in that directory, the relevant memories load automatically.

You can also direct the system explicitly. Saying "remember that we always use Newey-West standard errors with four lags in this paper" produces a memory file that loads in every future session in this directory. Saying "forget the rule about figure naming" removes it.

Memory is per-working-directory. Memories saved while working in ~/research/paper-1 load only when you open a session there. To share knowledge across projects, write it into a global file (~/.claude/CLAUDE.md) or copy the memory into the new project's directory.

5.4Skills for reusable workflows

A "skill" is a reusable workflow that lives in ~/.claude/skills/<skill-name>/SKILL.md. The file has YAML frontmatter declaring the name and a short description, and a Markdown body containing the instructions the agent follows when the skill is triggered. Unlike CLAUDE.md (which loads in one directory) and unlike auto memory (which loads in one directory), skills are global and activate based on intent: when your request matches a skill's description, the agent loads that skill's body and follows it.

Useful research skills you might create:

• draft-referee-report — given a paper PDF, draft a structured report in your preferred format (summary, contribution, strengths, concerns, minor comments).
• update-cv — given a new working paper, edit cv.tex to add it under "Working Papers" in chronological order, then rebuild the PDF.
• fetch-and-cache — given a URL or API call, download the file, save it to data/external/, and append a source-log entry to data/README.md.
• reply-to-referees — given a referee report and a revised paper, draft a point-by-point response letter cross-referenced to the revised manuscript.

Minimal skill structure:

$ mkdir -p ~/.claude/skills/draft-referee-report
$ $EDITOR ~/.claude/skills/draft-referee-report/SKILL.md

---
name: draft-referee-report
description: Use when given a manuscript PDF and asked to draft a referee report.
---

Steps:
1. Read the manuscript PDF in full. Note the journal name if present.
2. Produce a draft report with sections:
   Summary (one paragraph), Main contribution, Strengths,
   Major concerns, Minor comments.
3. Cite specific page or equation numbers in concerns.
4. Save as report.md alongside the manuscript.

For community skills, install the Anthropic Superpowers plugin — it bundles dozens of pre-built skills for planning, debugging, testing, code review, brainstorming, and more.

5.5Subagents and parallel work

Claude Code can dispatch subagents for parallel work. If you have three independent tasks — "fetch this dataset," "draft a referee report on that paper," "regenerate figures from the new estimates" — the main agent can spawn three subagents in parallel, each working on one task. They run independently, return short reports, and the main session integrates them.

This is most useful in two cases:

• Genuinely independent tasks with no shared state — the wall-clock saving is real.
• Tasks that involve heavy reading (a literature review, a long PDF). A research subagent reads twenty papers and returns a one-page summary; the main session never has to load that volume of text into its own context.

Trigger this behavior with the phrase "in parallel" in your prompt, or let the agent decide. Each subagent uses tokens, so plan accordingly: Max 20× is much more comfortable with three concurrent subagents than Pro or Max 5×.

6.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.