[FEATURE] Feature request: Remote compute target support (SSH + Slurm/PBS job scheduler integration)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

I'm a PhD candidate in Biostatistics at the University of South Carolina, developing an R package for Parameter-Expanded Variational Bayes (high-dimensional sparse regression). My daily workflow is:

Develop locally on my Arch Linux workstation with Claude Code (write R/Rcpp code, debug algorithms, create unit tests)
Run large simulations on university HPC (CentOS, Slurm scheduler) — hundreds of array jobs, each taking hours
Pull results back locally for figure/table generation and paper writing

I mount my HPC filesystem locally via SSHFS, so Claude Code can already see and edit all HPC files. But Claude Code cannot execute remotely — it can't submit Slurm jobs, monitor their status, or read logs without me manually running SSH commands in a separate terminal.

This creates a constant context-switching tax. Every time Claude Code writes a simulation script and says "now submit this with sbatch," I have to leave the Claude Code session, open a terminal, SSH in, run the command, wait, check status, come back, and tell Claude Code what happened. This breaks flow dozens of times per day.

Proposed Solution

Add a concept of remote execution targets in Claude Code configuration. Something like:

// In .claude/settings.json or CLAUDE.md
{
  "remoteTargets": {
    "hpc": {
      "transport": "ssh",
      "host": "hpc.sc.edu",
      "user": "polejua",
      "scheduler": "slurm",
      "workDir": "/work/polejua/",
      "localMount": "/home/peter/hpc/"
    }
  }
}

With this, Claude Code could:

Submit jobs: claude> run this simulation on hpc → Claude Code generates the script, calls ssh hpc.sc.edu "sbatch /work/polejua/sim/script.sh", captures the job ID
Monitor jobs: Periodically check squeue and notify when jobs complete
Read remote output: Know that /home/peter/hpc/results/ maps to /work/polejua/results/ on HPC
Full loop: Write script → submit → wait → read results → generate figures — all without the user touching SSH

Who This Helps
This isn't a niche use case. Every computational researcher at a university — statistics, bioinformatics, physics, chemistry, ML — has this exact workflow pattern: develop locally, execute on cluster. Supported schedulers would include Slurm, PBS/Torque, SGE, and LSF, covering virtually every academic HPC system worldwide. The same pattern applies to cloud compute (AWS Batch, GCP, etc.).

Local: Arch Linux, Ryzen 5 7600, 64GB RAM, Konsole/zsh
HPC: CentOS, Slurm, mounted via SSHFS

Alternative Solutions

Current Workaround
I use shell aliases and SSHFS mounts, but it's manual and breaks the agentic flow. Claude Code is incredibly powerful locally but becomes a "write-only" tool for HPC work — it can write the scripts but can't close the loop.
Environment

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

Here's a concrete scenario from your actual dissertation work:

Use Case Example: Running a Simulation Study for SpexVB
Context: I'm developing an R package called spexvb — Parameter-Expanded Variational Bayes for sparse high-dimensional linear regression with spike-and-slab priors.

R package: spexvb (Parameter-Expanded Variational Bayes)
Publication: doi.org/10.21203/rs.3.rs-7208847/v1

My dissertation requires large-scale simulation studies comparing my method against competitors (e.g., LASSO, Horseshoe, EMVS) across varying dimensions (p = 500, 1000, 5000), sample sizes, sparsity levels, and signal strengths. Each simulation needs hundreds of replications to produce reliable results.
My HPC is mounted locally via SSHFS, so Claude Code can already read and edit every file on the cluster.
What I want to happen (proposed):

• Step 1 — I describe the study to Claude Code: "I need a simulation study comparing spexvb against glmnet LASSO and horseshoe for n=200, p in {500, 1000, 5000}, with 500 replications each. Measure variable selection accuracy (TPR, FDR), estimation error (L2), and runtime. Run it on HPC."

• Step 2 — Claude Code writes the simulation script on the mounted HPC path (~/hpc/work/polejua/spexvb/sim/), including an R script that reads SLURM_ARRAY_TASK_ID to determine which scenario and replication to run.

• Step 3 — Claude Code generates and submits the Slurm job: It writes a sim_study1.sh Slurm batch script with --array=1-1500 (3 settings × 500 reps), appropriate memory/time/CPU requests, and then executes:

bashssh hpc.sc.edu "cd /work/polejua/spexvb && sbatch sim/sim_study1.sh"

→ Submitted batch job 4821537

• Step 4 — Claude Code monitors the job: It periodically checks squeue -j 4821537 and sees jobs completing over the next few hours. When all 1500 array tasks finish, it notifies me.

• Step 5 — Claude Code reads the results and builds the output: It reads the .rds files from ~/hpc/work/polejua/spexvb/results/sim_study1/, aggregates them into summary tables (mean TPR, FDR, L2, runtime with standard errors), generates publication-quality figures using ggplot2 locally, and writes a LaTeX table I can paste directly into my Overleaf dissertation.

What actually happens today (current reality):

Steps 1 and 2 work great — Claude Code writes beautiful simulation code. Then everything breaks:

Step 3: Claude Code says "Now run sbatch sim/sim_study1.sh on your HPC." I leave the Claude Code session, open Konsole, type ssh hpc.sc.edu, navigate to the directory, run sbatch, copy the job ID.

Step 4: I manually run squeue -u polejua every 30 minutes for hours. Claude Code is sitting idle the entire time — it has no idea what's happening.

Step 5: I come back to Claude Code and say "The jobs finished, results are in ~/hpc/work/polejua/spexvb/results/sim_study1/". Claude Code picks back up, but I've lost all conversational context from the hours of waiting, and often have to re-explain what the simulation was doing.

The gap: Claude Code can write the code and read the results, but the middle part — submit, monitor, resume — requires me to act as a manual bridge between Claude Code and the HPC. For a single simulation study this is annoying. For a dissertation with dozens of studies across multiple chapters, it adds up to weeks of lost productivity.

Additional Context

_No response_