23.1. Using Agentic AI on the Cluster#

This page sets up an agent on the Kempner AI cluster and covers how to run it day to day. The steps use Claude Code as the example; other terminal agents work the same way, and IDE agents connect through VS Code.

23.1.1. Before you start#

Warning

Cloud-based agents send your prompts, and any code or data they can read, to an external provider. FASRC permits generative AI tools on the cluster only for non-sensitive, public data (security Level 1). Do not point a cloud agent at Level 2 or higher data unless your school has arranged a contractual agreement with the provider first. See FASRC’s AI Agents guidance and Anthropic guidance, Agentic AI Tools for approved-tool data levels, and Security and Compliance.

In practice, Level 1 means public material, such as public repositories and datasets, or made-up data. Most unpublished research code, data, and results are Level 2; see Data classification and what the cluster can host. Before you point a cloud agent at them, check with your school whether your account is covered at that level.

You also need the Claude or ChatGPT access Harvard provides (see the sign-in step below), and a compute node. Do not run agents on a login node, where their processes would compete with every other user.

23.1.2. Running a terminal agent#

1. Start tmux and an interactive job. Start tmux on the login node, so a dropped connection does not end your session (see Keeping a session alive). Inside it, request a job. The agent only needs CPU and memory to talk to its model, so a small CPU allocation is enough:

tmux new -s agent
salloc --partition=test --time=0-02:00 --mem=16G --cpus-per-task=4

Request a GPU only when the agent will run GPU code for you. For short GPU checks, the kempner_interactive partition offers small GPU slices; see Understanding SLURM.

2. Install Claude Code.

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

This installs to ~/.local/bin, which must be on your PATH, and updates itself. If claude is not found, see the FAQ.

module load python
mamba create -n claude -c conda-forge "nodejs>=22"
source activate claude
npm install -g @anthropic-ai/claude-code

Claude Code is then on your PATH only while that environment is active. See Conda Environment.

If you run agents in several jobs at once, turn off automatic updates, because your home directory is shared and an update in one job can delete the version another job is running. Add this to ~/.claude/settings.json, and run claude update yourself when no agent jobs are running:

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

A settings file holds one JSON object. When later pages add settings, merge them into that object rather than pasting a second one.

3. Sign in with your Harvard account. FASRC states that using personal accounts or API keys for work on the cluster is not in accordance with Harvard policy; see its AI Agents guidance. Use the Claude or ChatGPT access that HUIT provides through Harvard SSO instead.

Run claude, or /login inside a session, and log in with your Claude account. Over SSH, it prints a URL: open it in your local browser, sign in with Harvard SSO, and paste the code it shows back into the terminal. Run /status to check that the organization is Harvard’s, not a personal one. The login is saved in your home directory, so it works on every node and in batch jobs.

Run codex login --device-auth, open the link it prints in your local browser, sign in to ChatGPT with Harvard SSO, and enter the one-time code. Device code login is in beta, and for a workspace account such as ChatGPT Edu, the workspace admin must turn it on first. See the Codex authentication documentation.

Leave ANTHROPIC_API_KEY unset. If it is set, for example in ~/.bashrc, Claude Code can use it instead of your Harvard login, and print mode (claude -p) always does.

4. Start the agent from your project directory. For your first sessions, use manual mode, which asks before edits and before commands that change things: claude --permission-mode default.

23.1.2.1. Permission modes#

Permission modes trade oversight for speed. Press Shift+Tab in a session to cycle through them, or choose one at startup with --permission-mode. New interactive sessions start in auto mode where it is available, and otherwise in manual mode.

Mode

Value

What it does

Manual

default

Asks before file edits and commands that change things; reads and read-only commands such as ls, cat, and grep run without asking. The safest mode while you learn.

Auto-accept edits

acceptEdits

Applies file edits and common filesystem commands, including rm, inside the project without asking.

Plan

plan

Researches and proposes a plan without editing files. Where auto mode is available, a classifier can still approve shell commands.

Auto

auto

Runs without routine prompts while a classifier blocks risky actions. Needs a supported model, and an organization can turn it off.

Don’t ask

dontAsk

Refuses anything that would need approval, so the agent only reads, runs read-only commands, and does what your rules allow. For unattended runs; see Caps on unattended runs.

Warning

Do not use --dangerously-skip-permissions (bypass mode) on the cluster. It runs any command without asking, and Anthropic recommends it only in isolated environments without internet access, which compute nodes are not.

23.1.2.2. Keeping a session alive#

A session lives inside your SSH connection, so it ends when your laptop sleeps or the VPN drops. Run it inside tmux on the login node:

hostname                 # note the login node, for example boslogin07.rc.fas.harvard.edu
tmux new -s agent        # then run salloc and claude inside tmux

If the connection drops, SSH back to that same login node and reattach:

ssh <username>@boslogin07.rc.fas.harvard.edu
tmux attach -t agent

A tmux session exists only on the node where you started it, and monthly maintenance reboots login nodes; see FASRC’s terminal access guide for the login nodes and their limits. tmux does not extend your job: the session still ends at the job’s --time limit. FASRC also ends a command-line interactive session after an hour without input. For long work you will not watch, run the agent in a batch job instead; for long interactive work, use Open OnDemand.

To pick up a conversation after your job ends, start a new job, cd to the same project directory, and start Claude Code there:

  • claude --continue reopens the most recent conversation in that directory, but not one started with claude -p.

  • claude --resume lets you choose an earlier conversation, or takes a session ID.

Conversations are saved under ~/.claude/projects/, so you can resume them from any node. Background sessions (claude --bg) run without a terminal, but they still end when your job does, so they do not replace tmux. To check on a session from another device, reattach tmux rather than turn on remote control; see Remote control.

23.1.2.3. Long or unattended runs#

For long tasks, run the agent in print mode (claude -p) in a batch job, with the limits in Caps on unattended runs; for a complete example, see SLURM Jobs and Cluster Workflows.

23.1.3. Running an IDE agent#

  1. Connect VS Code to a compute node with Remote-SSH, as described in VSCode for Remote Dev.

  2. Install the agent’s extension (for example Claude Code or Codex) with its Install in SSH button, so it runs on the cluster side.

  3. Sign in through the extension with your Harvard account, as in Running a terminal agent.

FASRC also documents editor and notebook extensions, including Jupyter AI in JupyterLab through Open OnDemand; see its AI extensions guidance.

23.1.4. Responsible use on shared infrastructure#

  • Stay within your allocation. Run agents in an interactive or batch job, never on a login node, and do not let an agent submit unbounded jobs or start long-running processes without your review; see Understanding SLURM.

  • Do not hold GPUs idle. Use a CPU allocation for reading, planning, and editing, and release sessions you are done with.

  • Review before it acts. Read the commands an agent proposes, especially anything that deletes files, rewrites history, or moves data.

  • Watch cost and quota. Track your account’s usage limits and your fairshare; see Watch cost and context.

  • Protect secrets and data. Keep keys out of repositories and shared paths, and block the agent from reading credentials; see Agent security.

23.1.5. Common pitfalls#

  • The agent tries sudo or system installs. You do not have root on the cluster; keep changes in your own directories and environments.

  • The agent cannot reach the provider’s API. Compute nodes have outbound access, so check your key and environment first; then see Support and Troubleshooting.

  • The session ends with your connection or job. Run it in tmux and resume the conversation; see Keeping a session alive.

  • SLURM commands stall inside the agent sandbox. Exclude them from it and run them as simple calls; see Agent sandboxing.

For sign-in problems and claude: command not found, see the agentic AI entries in the FAQ.

See also

For a hands-on walkthrough, see Your First Agentic Workflow on the Cluster. For prompt injection, remote control, scoping, and the agent sandbox, see Agent Security and Scoping. To keep everything on the cluster, see HPC Agentic Recipes.