Package Exports

This package does not declare an exports field, so the exports above have been automatically detected and optimized by JSPM instead. If any package subpath is missing, it is recommended to post an issue to the original package (execfence) to support the "exports" field. If that is not possible, create a JSPM override to customize the exports field for this package.

Readme

ExecFence

ExecFence is a local execution guardrail for projects that run code during development, build, test, CI, packaging, publishing, or agent workflows.

It was created for a specific failure mode: a repository looks like normal source code, but contains injected code, suspicious scripts, task files, package hooks, binaries, archives, or agent/tool configuration that can execute when a developer or coding agent runs an ordinary command.

Full documentation: chrystyan96.github.io/ExecFence

Technical detection reference: Detection Model

OpenAI Skills catalog PR: openai/skills#385

Why It Exists

Public incidents increasingly show developer machines being targeted through project execution paths, not only through deployed applications. Examples include fake interview repositories, malicious package lifecycle hooks, suspicious editor tasks, and compromised packages that execute during install or build.

Background reading:

Trend Micro: Void Dokkaebi Uses Fake Job Interview Lure to Spread Malware via Code Repositories
Microsoft: Contagious Interview: Malware delivered through fake developer job interviews
Datadog Security Labs: Compromised axios npm package delivers cross-platform RAT

ExecFence does not replace antivirus, EDR, dependency review, secret scanning, or SCA. It adds a local fence at the moment suspicious repository content would become active: before test, build, dev, pack, publish, CI, or agent-driven execution.

Two Ways To Use ExecFence

ExecFence has two installation/use paths. They are related, but they do not do the same thing.

Path	Runs where	What it does	Use it when
npm CLI: `npx --yes execfence ...`	Terminal, package scripts, CI	Actually scans files, gates commands, writes reports, audits dependencies, and returns blocking exit codes	You want protection now, without relying on an agent
Agent skill: `npx --yes execfence install-skill`	Codex and compatible agent instruction systems	Installs instructions telling agents when and how to use the ExecFence CLI	You use Codex or other coding agents on persistent projects
Project agent rules: `install-agent-rules --scope project`	Repository-local agent instruction files	Carries ExecFence rules with the project so agents see them in future sessions	You want the repo itself to instruct agents to run ExecFence

The CLI is the enforcement tool. The skill is the operating rule for agents. For agent-heavy work, install both.

Use The npm CLI

Run ExecFence without a global install:

npx --yes execfence scan

Gate a command before it runs:

npx --yes execfence run -- npm test
npx --yes execfence run -- npm run build

Run the CI guardrail bundle:

npx --yes execfence ci

Initialize project config:

npx --yes execfence init --preset auto

Check whether build/dev/test entrypoints are protected:

npx --yes execfence coverage

Preview or apply wrappers around risky entrypoints:

npx --yes execfence wire --dry-run
npx --yes execfence wire --apply

Audit package contents before publishing:

npx --yes execfence pack-audit

Use sandbox planning/audit mode:

npx --yes execfence sandbox doctor
npx --yes execfence sandbox plan -- npm test
npx --yes execfence run --sandbox-mode audit -- npm test

Use sandbox enforcement when available:

npx --yes execfence run --sandbox -- npm test

If the requested enforcement capability is unavailable, ExecFence should block before execution and explain what is missing. It does not silently downgrade enforcement.

Use The Skill

Install the skill:

npx --yes execfence install-skill

The skill is for Codex and compatible coding agents. It teaches the agent to:

run execfence scan before risky build/dev/test actions
prefer execfence run -- <command> when executing project commands
use sandbox audit/planning when available
avoid ignoring critical or high findings without an explicit, justified baseline
preserve .execfence/reports/ evidence instead of deleting suspicious files automatically
check agent/MCP/tool configuration changes with execfence agent-report

The skill does not scan a repository by itself. It makes the agent call the CLI.

Skill installation writes global defaults under:

<home>/.agents/skills/execfence/defaults.json

Treat that file as package/skill-owned reference data. Users should normally edit project config in .execfence/config/, not the global defaults file.

Add Project-Local Agent Rules

To make a repository carry ExecFence guidance for future agent sessions:

npx --yes execfence install-agent-rules --scope project

Verify configured rules:

npx --yes execfence install-agent-rules --verify

These rules are intended for Codex, Claude, Gemini, Cursor, Copilot, Continue, Windsurf, Aider, Roo, Cline, and similar tools. They tell agents to use the CLI before executing project code.

Project Configuration

After init, ExecFence uses a project-local .execfence/ directory:

.execfence/
  config/
    execfence.json
    signatures.json
    baseline.json
    sandbox.json
  reports/
  cache/
  quarantine/
  trust/
  manifest.json

Main user-editable files:

File	Purpose
`.execfence/config/execfence.json`	Main project policy: mode, policy packs, fail/warn severities, reports, enrichment, CI behavior
`.execfence/config/signatures.json`	Project-specific detection signatures
`.execfence/config/baseline.json`	Time-bound, owner-backed exceptions for known findings
`.execfence/config/sandbox.json`	Sandbox audit/enforcement profile and filesystem/process/network policy
`.execfence/trust/*.json`	Trusted files, registries, package scopes, actions, and package sources

Reports are written to .execfence/reports/ by default. ExecFence adds this directory to .gitignore unless project config sets reports to be versioned.

When ExecFence Blocks

Do not rerun the same command outside ExecFence just to get past the block. Start with the report:

npx --yes execfence reports latest
npx --yes execfence reports open

Create an incident bundle:

npx --yes execfence incident bundle --from-report .execfence/reports/<report>.json

If a finding is legitimate and must be allowed, baseline it with an owner, reason, expiry, and hash:

npx --yes execfence baseline add --from-report .execfence/reports/<report>.json

Baselines are meant for reviewed exceptions, not for forcing a build through unknown critical or high findings.

Common Commands

Command	Purpose
`execfence scan`	Static project scan
`execfence run -- <command>`	Preflight scan, command execution, post-run evidence report
`execfence ci`	Combined CI guardrail bundle
`execfence coverage`	Detect unprotected build/dev/test entrypoints
`execfence wire --dry-run`	Show wrapper changes without writing
`execfence wire --apply`	Apply wrappers where supported
`execfence manifest`	Generate execution-entrypoint manifest
`execfence manifest diff`	Detect new or changed execution entrypoints
`execfence deps diff`	Compare dependency/lockfile risk
`execfence pack-audit`	Audit package contents before publish
`execfence agent-report`	Review agent, MCP, tool, and instruction-file changes
`execfence reports latest`	Show the latest report
`execfence report --html <report.json>`	Generate a local HTML report
`execfence sandbox doctor`	Check local sandbox capability
`execfence sandbox plan -- <command>`	Explain what sandbox policy would allow/block

execfence