Spike: run scheduled jobs through Sandcastle on Windows

Start with skills/report/scripts/schedule.mjs to see how claude -p is spawned today, and skills/report/scripts/report.mjs for the host-side report port. In a scratch repo run npx @ai-hero/sandcastle init, create .sandcastle/main.ts and .sandcastle/Dockerfile, then run npx tsx .sandcastle/main.ts in PowerShell and, if needed, WSL. Done means all seven checks have recorded pass/fail, command, environment and workaround, with the template files pushed.

Scheduled runs should run the agent in a container through Sandcastle, not with claude -p on the host. Then the agent can run without permission limits and without auto mode on the PC. This issue is a spike on the Windows PC. It answers the questions that decide how big the runner rewrite is. Run it on Windows, because Windows is the main target and Sandcastle doesn't say whether it supports Windows.

Background

gstack has three layers, and Sandcastle takes over the middle one.

1. What the agent knows. This is skills, playbooks and principles. gstack owns it. scripts/build.mjs renders it for each harness into dist/<harness>.
2. How the agent runs. This means starting the agent, isolating it, injecting the prompt and secrets, enforcing the timeout, collecting the result and cleaning up. Today skills/report/scripts/schedule.mjs does it with claude -p. Sandcastle's run() does it with an agent provider (claudeCode, codex, opencode and others) and a sandbox provider (docker, podman, vercel, noSandbox).
3. What reaches the user. This is the report port and its Telegram adapter, skills/report/scripts/report.mjs. gstack owns it, and it stays on the host.

The plan is a job spec run by a deterministic runner. A job spec holds the name, schedule, repo, branch strategy, harness, model, prompt or skill, timeout and report adapter. The OS scheduler starts the runner. The runner reads the spec, runs Sandcastle, and always sends a report afterwards, even when the run fails. gstack stays dependency-free. Instead of importing Sandcastle, it ships a template .sandcastle/main.ts and a Dockerfile snippet that live in the user's project.

Setup

WSL2 and Docker Desktop already run on the PC. Before starting:

• In Docker Desktop, turn on Settings > General > "Start Docker Desktop when you sign in". Scheduled runs need Docker running.
• Run npx @ai-hero/sandcastle init in a scratch repo.
• Run claude setup-token. This needs a browser, so a human does it. Put the token in .sandcastle/.env as CLAUDE_CODE_OAUTH_TOKEN, and check that .sandcastle/.env is gitignored.
• Make sure ANTHROPIC_API_KEY is set nowhere. Claude Code uses it ahead of the OAuth token, and in -p it always uses it. The run would then bill at API rates instead of using the subscription. Also don't pass --bare, because bare mode ignores CLAUDE_CODE_OAUTH_TOKEN. Both rules are in the authentication docs.

Checks

Run each check from Windows PowerShell first. If Sandcastle fails there on paths or the shell, repeat the check inside WSL Ubuntu, and record which one worked.

1. Sandcastle runs on Windows. npx tsx .sandcastle/main.ts with a trivial prompt finishes and returns a RunResult.
2. The subscription is used. In the run's output or session file, the auth method is the OAuth token, not an API key.
3. gstack skills load in the container. Add steps to .sandcastle/Dockerfile that copy in dist/claude-code (from npm run build) and run claude plugin marketplace add <dir> and claude plugin install gstack@gstack. Rebuild with sandcastle docker build-image. A prompt that starts with /gstack:report or /gstack:go-mode should load the skill in print mode. Don't mount the host ~/.claude, because it holds the login and the history.
4. The report comes back as structured output. Use output: Output.object(<report schema>) with maxIterations: 1. The schema takes the report fields, which are title, status (done, running, blocked, failed), summary, completed, blockers, next and links. run() returns the report. Pipe it into report.mjs on the host to send it to Telegram.
5. The Telegram token stays out of the container. With TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID set in the host shell, list the environment inside the container with env in a sandbox.onSandboxReady hook. Neither variable should appear. The README says sandbox env comes from .sandcastle/.env and process.env, and doesn't say whether it passes the whole environment.
6. An abort removes the container. Start a run that hangs, abort it through signal, then run docker ps -a. No container from the run should be left. Repeat by killing the node process from outside, which is what schedule.mjs does today on timeout, and record whether that leaves the container behind.
7. Branch strategy. branchStrategy: { type: "branch", branch: "gstack/<job>" } leaves the agent's commits on that branch and leaves the checked-out branch unchanged.

Done when

Each of the 7 checks has a recorded result, either in a comment here or in a short doc. Record pass or fail, the command run, PowerShell or WSL, and any workaround. The template main.ts and Dockerfile used for the checks are attached or pushed to a branch.

Out of scope

• The runner rewrite itself. It is a follow-up issue sized from these results. It adds the job spec, swaps the claude -p spawn in schedule.mjs for the Sandcastle script, and keeps the fallback failed report and the retry rules.
• Inbound commands from Telegram. That is a separate port, with its own security questions.
• Our own sandbox or agent providers.

🤖 Generated with Claude Code