Configuration

Precedence

Sigil resolves configuration from multiple sources. When the same setting appears in more than one place, the highest-priority source wins:

1. CLI flags — always win
2. Environment variables
3. Config file (~/.sigil/config)
4. Built-in defaults

Environment variables

Environment variables override config file values. Useful for CI/CD pipelines and per-machine customization.

# Store quarantined code on a separate volume
export SIGIL_QUARANTINE_DIR=/mnt/secure/sigil-quarantine

# Point Sigil at your own API instance
export SIGIL_API_URL=https://sigil.internal.mycompany.com

Directory structure

After running sigil config --init, Sigil creates the following directory layout:

~/.sigil/
├── quarantine/     # Untrusted code awaiting scan
├── approved/       # Code that passed review
├── logs/           # Scan execution logs
├── reports/        # Detailed scan reports
├── config          # User configuration file
├── token           # JWT auth token
└── signatures.json # Cached threat signatures

Config file

The config file at ~/.sigil/config uses a simple KEY=VALUE format.

API_URL=https://api.sigil.nomark.dev
AUTO_APPROVE_THRESHOLD=0
DEFAULT_SEVERITY=medium

View your current configuration:

sigil config

Create a default config file:

sigil config --init

.sigilignore

Place a .sigilignore file at the root of the directory being scanned. It uses glob syntax similar to .gitignore.

# Directories
node_modules/
.git/
__pycache__/
vendor/
dist/
build/

# File patterns
*.min.js
*.bundle.js
*.map
*.lock

# Specific files
package-lock.json
yarn.lock
poetry.lock

Default exclusions

Even without a .sigilignore file, Sigil automatically excludes:

• node_modules/
• .git/
• Test files
• Example files
• Docs files

Pattern rules

Scan policies

Team plans support centralized scan policies that are enforced across your organization. Configure policies via the dashboard or API.

Auto-approve threshold

Controls which verdicts are automatically approved without manual review.

Required review

Specify which verdicts must always go through manual review:

• HIGH / CRITICAL — always require review
• MEDIUM — optional (configurable per policy)
• All — require review for every result

Package allowlist

Packages on the allowlist are always approved and bypass scanning entirely.

{
  "allowlist": [
    "@myorg/shared-utils",
    "@myorg/config"
  ]
}

Package blocklist

Packages on the blocklist are always rejected, regardless of scan results.

{
  "blocklist": [
    "malicious-package-name",
    "deprecated-unsafe-lib"
  ]
}

Policy sync

Policies are synced via the cloud. Configure them through the dashboard or directly via the API:

# Fetch current policy
curl -H "Authorization: Bearer $SIGIL_TOKEN" \
  https://api.sigil.nomark.dev/v1/team/policy

# Update policy
curl -X PUT -H "Authorization: Bearer $SIGIL_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"auto_approve_threshold": 0, "required_review": ["high","critical"]}' \
  https://api.sigil.nomark.dev/v1/team/policy

Shell aliases

Sigil can install convenience aliases into your shell configuration.

Installation

Auto-detect your shell and append aliases:

sigil aliases

Or print them to stdout without modifying any files:

sigil aliases --print

Alias definitions

Customization

Use --print to output the alias block, then manually add or modify entries in your shell config.

Removing aliases

Delete the block between the # SIGIL ALIASES comments in your shell configuration file.

Git hooks

Sigil can install a pre-commit hook that checks staged files for dangerous patterns before every commit.

Installation

# Install in the current repo
sigil hooks

# Install in a specific repo
sigil hooks /path/to/repo

Patterns checked

The pre-commit hook scans staged files for known dangerous patterns:

• eval(
• exec(
• __import__(
• subprocess shell=True
• os.system
• pickle.loads
• child_process

Behavior

When a finding is detected, the hook exits with code 1 and blocks the commit. To bypass the hook for a specific commit:

git commit --no-verify -m "known safe: template engine uses eval"

Authentication

Sigil uses JWT tokens for cloud features (Pro and Team plans). The open-source CLI works entirely offline without authentication.

Token storage

Tokens are stored at ~/.sigil/token as a JWT. The token is issued with an expiration, read on each API request, and Sigil falls back to offline mode if the token is expired or missing.

What data is sent

Sigil sends metadata only to the cloud API. Source code never leaves your machine.