The magical auto permission mode

Recently (May 2026), Claude Code introduced an auto permission mode. Whereas default asked about everything and dontAsk was extremely limited in what it could do, auto uses its (considerable!) judgement about what’s safe or not. Invoking claude --permission-mode auto will activate this mode (and this setting will persist across sessions, including in e.g. VS Code). This mode doesn’t eliminate permission prompts, but removes ~99% of them, which makes it much more feasible to give Claude a big task and then walk away.

If you don’t want to give Claude auto access to your own computer, a good alternative is to spin up a virtual machine, clone the repo you’re working on, and start a Claude session there. (You don’t need a big VM; even just a “free tier” VM will probably suffice.) But then it’s running on a VM, and that means it’s a pain to access, right? Not necessarily …

Watching from afar

Note: Claude provides a feature called Remote Control that lets you control sessions from the web, but this can be fragile for long-running sessions, and isn’t available on all accounts.

Since our coding agent is running in the terminal, ssh is the tool of choice for linking different devices, including phones. But it’s typically a paint to SSH directly from one device to another, thanks to the (very worthwhile) security measures like firewalls.

While there are again multiple ways to solve this this, a simple (and free, though proprietary) solution is Tailscale. Installing Tailscale on your laptop and phone (and/or VM) effectively creates a personal VPN connecting the devices, letting you interconnect them from anywhere.

The last step of the process is how to keep the Claude session running even if you disconnect from it – which is the problem tmux solves. You can start a tmux session on the VM, then connect to it and control it from both your phone and laptop.

To recap, the steps are:

1. Install & sign into Tailscale on each of your devices
2. Ensure your “main” device (your laptop or VM) has an SSH server running
3. Start a tmux session on the main device, e.g. tmux new -s claude
4. Start a Claude session inside the tmux session
5. Give it a task to get started with
6. SSH into the main device from your phone or other device
7. Connect to the tmux session: tmux attach -t claude

Now you can control the Claude session from your other device.

How we’ve used this in Starsim

For literally years, we’ve put off the task of migrating Covasim into the Starsim framework. But Covasim still has an active user base, so we wanted to prioritize getting the port done.

Porting Covasim is a huge task: ~10,000 lines of code, much of it written 5+ years ago. However, it is also fairly well-defined: the code should use Starsim classes, but produce (statistically) identical results to the current version of Covasim. Plus, we’ve ported HPVsim to Starsim, which has a similar structure to Covasim.

This was the perfect task for this workflow. I started a Claude session on a VM with --permission-mode auto, gave it a detailed 10-step spec for doing the port, and told it to check in after each step for approval. The port took Claude roughly 14 hours (with less than half an hour human time), and I was able to monitor progress and approve steps from my phone.

The reference model

Mike Famulare and Wesley Wong built a multiscale agent-based model for Sabin 2 poliovirus transmission in Bangladesh, described in “Multiscale model for forecasting Sabin 2 vaccine virus household and community transmission”. The model captures community structure at three nested scales — households within baris (neighborhood compounds) within villages — with age-assortative mixing at each level. Transmission is driven by a dose-response function where viral shedding accumulates across contacts and immunity modulates susceptibility through a Hill-equation-style curve.

The original Python implementation lives at InstituteforDiseaseModeling/community-structure-mediates-polio-transmission. Our Starsim port is at starsimhub/starsim-community-structure.

Dose-response in Starsim

The core challenge: Starsim’s Infection.step() processes each network edge independently — P = beta * rel_trans * rel_sus. But for dose-response, we need to accumulate dose across all edges first, then apply a nonlinear function once per person. This required a new base class, DoseResponseInfection, that overrides the transmission step.

The dose-response formula from the reference model:

where is accumulated dose, is a strain-specific scale parameter, controls the shape, and controls how immunity dampens susceptibility. Higher NAb (neutralizing antibody) immunity flattens the curve — you need exponentially more dose to infect.

The transmission step has two phases. First, accumulate dose from all networks using np.add.at (which safely handles multiple edges to the same person):

def accumulate_dose(self):
    self.challenge_dose[:] = 0.0
    for network in self.sim.networks.values():
        p1, p2, beta_edge = network.edges.p1, network.edges.p2, network.edges.beta
        scale = self.pars.beta * self.pars.fecal_oral_dose
        np.add.at(dose_raw, p1, scale * beta_edge * rel_trans_raw[p2])
        np.add.at(dose_raw, p2, scale * beta_edge * rel_trans_raw[p1])

Then, challenge susceptibles using the dose-response function. Each person’s infection probability is computed from their total accumulated dose and current immunity:

@staticmethod
def infection_prob_func(module, sim, uids):
    dose = module.challenge_dose[uids]
    nab = module.immunity_nab[uids]
    p = module.pars
    return 1 - (1 + dose / p.beta_scale) ** (-p.alpha * nab ** (-p.gamma))

This function is passed to ss.bernoulli(p=infection_prob_func), which Starsim evaluates per-agent — each susceptible person rolls against their individual infection probability. Because dose is summed linearly before the nonlinear transform, it doesn’t matter whether you get dose 10 from one contact or dose 5 from two — the total dose is the same. What the nonlinearity does capture is that infection probability saturates at high dose (diminishing returns) and that immunity reshapes the entire curve rather than simply scaling it.

In-host dynamics

The within-host biology is faithfully ported from the reference model:

Immunity waning uses power-law decay (not exponential): . This distinction matters for OPV reversion epidemiology — power-law decay has a long tail where immunity remains above baseline for years, unlike exponential decay which rapidly returns to zero.

Shedding intensity varies with time since infection, age, and immunity. Infants shed at peak concentrations of CCID50/g while adults peak at , and pre-existing immunity further reduces the peak. The temporal profile follows a log-normal-in-time shape:

predicted = (10**peak_cid50) * np.exp(
    eta - 0.5 * v**2 - (log_term**2) / (2 * variance**2)
) / t_days
self.viral_shed[uids] = np.maximum(shed_min, predicted)

Shedding duration is immunity-dependent and lognormally distributed — higher pre-challenge immunity shortens shedding. The model supports four poliovirus strains (S1, S2, S3, WPV) with strain-specific parameters for , shedding duration, and variance.

Multi-scale network

The reference model’s network operates at three scales: household, bari (neighborhood), and village. A key insight from the reference implementation: contacts are only generated FROM infectious agents, not from the entire population. In the original code, Transmission objects are created only for shedding individuals, and these drive contact sampling at each scale.

We replicated this pattern in Starsim by having BariNet and VillageNet check the disease module’s is_shedding state in add_pairs(). Our initial implementation generated contacts for all agents every timestep, which was faithful but slow — O(n_agents) per step. Switching to infectious-only contact generation brought this down to O(n_infectious), matching the reference model’s design and cutting runtime from minutes to seconds. Both the reference model and our port run at dt = 1 day, with contacts sampled fresh each timestep — no persistent edges. In Starsim, this is achieved by setting dur=0 on bari/village edges. (Starsim does support persistent edges with dur > 0 if longer-lasting contact relationships are needed for other applications.)

At each scale, contacts are sampled with age-weighted probabilities from 81x81 age-mixing matrices. The bari layer uses a 3-Gaussian mixture (capturing multi-generational household structure), while the village layer uses a 1-Gaussian + uniform background model. Here are the empirical sampling distributions compared to the reference matrices:

The three layers are mutually exclusive: household handles within-household, bari handles within-bari excluding own household, and village handles between-bari contacts.

Results

The full model runs 1000 agents over 2 years in ~4 seconds — fast enough for interactive exploration. Here’s a sample epidemic with Sabin type 2:

What’s Next

• Generalize DoseResponseInfection into Starsim core — the base class is disease-agnostic and could support cholera, norovirus, rotavirus, and other fecal-oral pathogens
• CRN-safe networks — we explored several approaches (1D CDF embedding, multi-pass per-Gaussian, seeker/target interleaving) but found that nearest-neighbor matching in small baris (~50 agents) doesn’t produce sufficient age structure. This remains an open design challenge.
• Realistic demographics — replace synthetic DHS data with actual household composition data from Bangladesh

Code: starsimhub/starsim-community-structure