Resource Safe Execution is a cross-platform Agent Skill that inspects CPU, memory, disk, GPU visibility, and running processes; chooses bounded concurrency; verifies acceleration instead of assuming it; and cleans up only processes the agent started.
Watch the 38-second proof · Read the safety model · See compatibility evidence
No telemetry · No network access · Python standard library only · SHA-256 release manifest · Windows/macOS/Linux CI
The open skills CLI can install the canonical folder:
npx --yes skills@1.5.20 add pntech20/resource-safe-execution --skill resource-safe-execution --copyThe third-party skills CLI records anonymous, opt-out install telemetry used
by skills.sh. Resource Safe Execution itself sends no telemetry and performs no
network access.
After installation, try:
Before running this build and eight browser workers, inspect my machine, choose a safe profile, track every process you launch, and clean up only your owned tree.
For a reviewed, release-pinned copy:
npx --yes skills@1.5.20 add https://github.com/pntech20/resource-safe-execution/tree/v0.2.0/skills/resource-safe-execution --skill resource-safe-execution --copyBefore use, verify the nine copied paths against
skill-manifest.json and SHA256SUMS.
The detailed manual-copy procedure and client destinations appear below.
Resource-heavy coding tasks can make a workstation unresponsive, exhaust disk space, or leave child processes behind. Resource Safe Execution gives an agent a conservative workflow for inspecting the host, choosing bounded concurrency, monitoring work, and cleaning up only processes it started.
The canonical Agent Skill combines portable policy with a Python 3.10+ probe for read-only host inspection of CPU, memory, disk, GPU visibility, and privacy-preserving process summaries. On POSIX, its only optional write is an explicitly requested output file. The current Windows probe requires stdout because the standard library cannot create a file relative to a held directory handle without an ancestor path race. Platform-specific guidance is loaded from direct local links in the skill folder.
A real orphaned headless-browser incident combined forced CPU software rendering with detached execution and missing cleanup. The anonymized case study traces the evidence and root cause. The dependency-free owned browser lifecycle example shows how to record ownership, use an internal deadline, close on every exit path, and verify the owned root exited.
The bundled runtime uses only the Python standard library. It performs no network access, telemetry, package installation, or privilege escalation. It never terminates pre-existing or unrelated processes. Diagnostic calls have a five-second execution deadline plus a fixed 0.25-second cleanup grace. The parent drains stdout and stderr through operating-system pipes without reader threads or backing files, then closes them when the owned child exits. This keeps at most one MiB of retained captured bytes plus operating-system-bounded pipe buffers, so descendant-held standard handles cannot extend the call. It does not bound the total bytes a child may attempt to write; the first observed byte above the retained limit is an output overflow. A timeout or overflow is a breach. Windows then stops only the child through its owned process handle, while POSIX stops the new owned process group.
Diagnostic executables never come from the project directory or inherited
PATH. Native Windows APIs provide the Windows and Program Files anchors; the
probe rejects reparse or current-token-writable trusted components and passes
only validated SystemRoot, WINDIR, ProgramFiles, and system-only
PSModulePath values. That module path excludes current-user PowerShell module
roots so Get-CimInstance cannot auto-load a user shadow. A Windows access
probe treats only ERROR_ACCESS_DENIED and ERROR_PRIVILEGE_NOT_HELD as
definitive absence of a requested dangerous right; sharing and transient
errors fail closed. POSIX candidates must be root-owned, executable, and
beneath a root-owned ancestor chain that is not group/other-writable or
exposed through a detectable ACL. Privileged system-directory mutation is
outside this unprivileged-shadowing boundary.
Process summaries exclude command lines, environment variables, usernames, file contents, tokens, and network destinations. Detection of GPU hardware is not presented as proof that an application uses a particular acceleration backend.
Review all executable skill contents, especially
scripts/resource_probe.py, before installation.
The safe default is a reviewed, checksum-verified copy:
- Use the exact reviewed release checkout.
- Verify the nine paths and SHA-256 hashes in the installation manifest against SHA256SUMS.
- Copy only those nine manifest-listed regular files, then verify the destination contains exactly the same paths and hashes.
Use the appropriate destination root:
| Client and scope | Destination |
|---|---|
| Codex project | .agents/skills/resource-safe-execution |
| Codex personal | ~/.agents/skills/resource-safe-execution |
| Claude project | .claude/skills/resource-safe-execution |
| Claude personal | ~/.claude/skills/resource-safe-execution |
| Antigravity workspace | .agents/skills/resource-safe-execution |
| Antigravity global | ~/.gemini/config/skills/resource-safe-execution |
The canonical folder follows the open Agent Skills specification. The documented destinations come from the official Codex, Claude Code, and Antigravity skill documentation.
Repository tests provide format and install validation for clean copies. They are not actual client runtime validation. See the compatibility evidence and limits before making a client-specific claim.
The current release is v0.2.0. Its release notes
describe the packaging and distribution changes. All 17 required
skill-enabled behavior signals are present in the
auditable evaluation, and
final-review provenance is hash-checked by the repository suite. The local
Codex installation contains the exact nine manifest-listed files.
Windows was physically exercised on this host with the live probe, both validators, and the repository suite. The hosted CI run passed all six Windows, macOS, and Ubuntu jobs on Python 3.10 and 3.13, including a live JSON smoke probe. Physical macOS, physical Linux, Claude Code, Antigravity, and other proprietary client runtime checks remain unperformed; no physical-host or client-runtime claim is inferred from CI.
python skills/resource-safe-execution/scripts/resource_probe.py --format jsonThe probe prints one JSON document. On macOS and Linux,
--output NEW_FILE performs an optional output-file write using POSIX
directory-handle-relative, no-follow traversal and exclusive creation. It
refuses existing files, symlinks, and invalid parent paths even if an ancestor
is swapped concurrently. The current Windows probe requires stdout and rejects
--output with exit code 1. Missing host metrics degrade individually with
a machine-readable reason.
python -m compileall skills tests
python -m unittest discover -s tests -v
python tests/validate_skill.py skills/resource-safe-executionProject releases use semantic versioning. The probe's JSON schema version changes only for incompatible data-contract changes; it is independent of documentation-only project releases.
Read CONTRIBUTING.md before proposing a change. Report vulnerabilities privately according to SECURITY.md.
Resource Safe Execution is available under the MIT License.