Agy Worker

Delegate repository work and verify the result

Delegate substantive exploration or implementation to agy, then inspect its diff and run driver-owned checks. Unknown files, architecture or a first test command do not prevent useful exploration; worker envelopes are not evidence.

SKILL_ROOT contains this file. In Claude Code it is ${CLAUDE_SKILL_DIR}, substituted in instructions rather than exported by Bash. Resolve the package:

PIPELINE="$(bash "$SKILL_ROOT/scripts/resolve-pipeline.sh")" || exit $?

Use "$PIPELINE/doctor.sh" --repo /absolute/path/to/target for offline readiness; ready proves neither authentication nor task success. See the Package README.

Authorize provider work

Obtain human approval for the task, exact provider-readable content, transmission and isolation modes, caller-selected model and budget. One upfront approval may cover predictable same-scope repairs and mechanical digest refresh. New scope, content exposure, destination, isolation, permissions or budget needs fresh authority. SHA values bind the documented controller inputs, not the entire human decision; refreshing a still-applicable binding is not another approval request. Goal and hand-authored JSON are not ordinary-use prerequisites.

Prefer --provider-scope FILE --approve-transmission-sha SHA256 for bounded jobs. It binds reviewed read entries, their content digest, and a write subset in a fresh owner-private mode-0700 Gitless stage. Whole-worktree dispatch requires --approve-whole-worktree LAUNCH_APPROVAL_SHA256. Every disposable-worktree entry is provider-readable and may reach Google/Gemini; --add-dir, prompt denylists and gate path policies do not narrow that read boundary. Neither workflow.sh run nor the advanced agy-worker.sh initial dispatch has an implicit transmission mode. The whole-worktree digest binds content, kinds, full file mode bits, symlink target hashes, the readable manifest, provider isolation and native grant profile. The scoped digest binds canonical read/write policy, readable path/kind manifest, selected bytes and executable bits, isolation and grant profile; scoped mode rejects symlinks and does not bind full POSIX permissions. The controller rechecks the approved boundary before provider start. The human approves one launch_approval_sha256 over canonical launch_authority: those content inputs, destination and Git base, exact normalized task and constructed prompt, fixed transport templates, workflow/edit mode, model/effort, cycles and time budgets, scoped repair, self-verification manifest digest, provider-env names, slash policy, additional directories and provider schema digest. Preview the exact task and all launch options; reuse them unchanged for the approved run. Only trailing LF bytes are removed from UTF-8 task input; spaces and CRLF are preserved. Environment values and private verification commands are never serialized into the approval payload. Use the private prelaunch review checklist in Project lifecycle and verification, including any optional self-verification commands, IDs and limits; keep that manifest out of the provider preview and prompt. Retired dispatch and workflow job formats are rejected; finish or discard them with their creating release, without migration. Default --provider-isolation session uses the existing AGY session. AGY has normal user filesystem/network authority; staging and reconciliation are not host isolation. Explicit --provider-isolation native requires supported macOS scoped containment; it never falls back to session mode. Preserve the recorded isolation mode and grant profile across repairs. Provider-scope approval grants neither provider execution, Git action, driver acceptance, nor publication. Exclude secrets, denied paths and unrelated private content from every approved entry; telling the worker not to read an approved entry is not a control.

Keep raw logs and controller state outside the worktree and prompts. Each launch requires capability preflight and immediate executable-binding recheck. Model and effort stay caller-owned. Child environment opt-ins require approval per variable name. Installation grants no provider or Git authority.

Read Security and compatibility before a first live dispatch or changing execution exposure. It owns native network/Keychain limits, verifier environments and no-follow boundaries. Read the required launch notices before initial, resume, continue or restart attempts; notices do not repeat approvals.