Spike: run scheduled jobs through Sandcastle on Windows

Ouverte
  • Quelque chose ne va pas ?
#65 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
30/100
Type d'issue
Fonctionnalité
Clarté
Clairement spécifiée
Activité
Active
Stack technique
docker, powershell, typescript
Domaine
devops, tooling

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement ready-for-human

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

Langage dominant
JavaScript
Étoiles
0
Forks
0
Merge moyen
1 j 3 h
PR mergées (30 j)
37

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de gregogun/gstack

Toutes les issues de gregogun/gstack

Issues similaires

Plus d'issues JavaScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.