Naar
Menu
Security

Naar is a safety layer, not a sandbox

Naar adds review, policy checks, and explicit confirmation before writes. It helps users make better decisions, but it does not claim to prove that third-party skills are harmless.

What Naar does

Naar scans repository files locally, fetches provider candidates, re-checks fetched bundles during install, previews writes, and asks for explicit approval before writing managed files.

What Naar does not do

Naar is not a sandbox, not an antivirus engine, not a formal security audit, and not a guarantee that a third-party skill is safe for production or private infrastructure.

What Naar does

  • Scans repository files locally to infer structured facts.
  • Keeps scan and recommendation separate from file writes.
  • Runs fetched-bundle content checks before install writes.
  • Blocks scripts by default and surfaces risky findings explicitly.
  • Requires review and confirmation during the install flow.

What Naar does not do

  • It does not upload your full source code to providers.
  • It does not rewrite application source files during scan or recommendation.
  • It does not silently install from search results.
  • It does not treat heuristic scores as security proof.
  • It does not replace careful review of installed files.

Trust boundaries

Scan and recommendation stay local-first. Providers may receive structured repo facts like frameworks, languages, or assistant targets, but Naar does not ship your full codebase for recommendation-time analysis.

Writes happen only in the install flow, after fetched-bundle review and an explicit install plan.

Review workflow

The install flow fetches the selected bundle, analyzes metadata and file content, shows a plan, and requires confirmation before writes. Risky installs can require stronger confirmation or explicit override flags.

Preview first

naar go --dry-run

Direct bundle preview

naar install clawhub:brewpage --dry-run

Files Naar may write

These are the managed project files Naar may create or update during install, depending on selected targets.

Path Reason
`.claude/skills/<skill>/SKILL.md` Stable write target for Claude project skills.
`.cursor/rules/naar-<skill>.mdc` Stable write target for Cursor rules.
`.github/copilot-instructions.md` Managed block updates for GitHub Copilot repo instructions.
`.agents/skills/<skill>/SKILL.md` Stable write target for Codex repo skills and generic agent skills.
`.naar/installed.json` Project-local managed state for currently installed skills.
`naar.lock.json` Pinned provider/version history for reproducible lifecycle operations.
`.naar/skills/<skill>/SKILL.md` Local copied source of fetched skill markdown for provenance and uninstall support.

Safe usage checklist

These habits are still your responsibility, even when Naar is doing the heavy lifting.

Prefer `--dry-run` before installing a new skill into a sensitive repository.
Read the generated install plan and then inspect the resulting `git diff`.
Treat risk and security scores as heuristics, not guarantees.
Be extra careful with skills that mention scripts, binaries, API keys, or shell access.
Use `naar uninstall` to remove managed files instead of deleting them manually.

Local history

Naar's lifecycle history is local-only and exists to support auditing and cleanup, not telemetry.

History scope

Local history can store project paths, path hashes, timestamps, broad stack facts, installed skill metadata, targets, security scores, and install/uninstall lifecycle events. It must not store source code, file contents, secrets, tokens, or shell history.

Need the full policy text?

The repository security document remains the detailed source of truth for exact policy thresholds and signal behavior.