Stats
Actions
Tags
From local-security
Run an automated security review of your local Claude Code setup. Checks disk encryption, MCP server health, dependency vulnerabilities, credential security, permissions audit, version pinning, stale credentials, and data flow risks.
How this skill is triggered — by the user, by Claude, or both
Slash command
/local-security:local-reviewThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Automated security checks for your Claude Code setup. Validates three risk areas: supply chain integrity, credential storage, and permission scope.
Automated security checks for your Claude Code setup. Validates three risk areas: supply chain integrity, credential storage, and permission scope.
Note: This skill requires Bash commands for system checks. Use Bash for all commands specified below, overriding the default preference for dedicated tools. Use the Read tool for reading JSON settings files.
Run all checks below in order. For each check, report PASS, WARN, or FAIL with a one-line explanation. Present a summary at the end.
If a check cannot run (command not found, file missing, not applicable), report it as INFO with context rather than FAIL.
Check whether the boot volume is encrypted.
macOS:
fdesetup status
Linux:
lsblk -o NAME,FSTYPE,MOUNTPOINT | grep -E "crypt|luks" || echo "No LUKS encryption detected"
Discover all MCP servers and verify the integrity of local ones.
Discover servers from Claude Code settings files (do not use claude mcp list — it is unreliable from inside a session).
Primary method — read settings files:
Use the Read tool to read ~/.claude/settings.json. Also read ~/.claude/settings.local.json if it exists (this file is not always present — skip without error if missing).
Then find project-level settings:
for dir in ~/Sites ~/projects ~/code ~/repos ~/dev ~/workspace ~/src; do
[ -d "$dir" ] && find "$dir" -name "settings.local.json" -path "*/.claude/*" 2>/dev/null | grep -v node_modules
done | sort -u
Read each project settings file found using the Read tool. Read files in batches of 3-4 to avoid tool call limits — do not attempt to read all files in a single parallel batch.
Parse the mcpServers object from each to identify registered servers. Optionally cross-reference mcp__* tool entries in permissions.allow arrays if any servers appear to be missing from the mcpServers blocks.
Secondary method — find servers not registered in settings files:
for dir in ~/Sites ~/projects ~/code ~/repos ~/dev ~/workspace ~/src; do
[ -d "$dir" ] && find "$dir" -maxdepth 3 \( -name "package.json" -o -name "pyproject.toml" \) -path "*mcp*" 2>/dev/null
done | sort -u
If a security assessment file exists (~/.claude/security-assessment.md), read it and cross-reference its MCP Server Inventory table against discovered servers to identify any changes.
If the common directories above don't cover the user's setup, ask where their development projects are located.
Classify each server as:
For each local MCP server discovered (has a git repo):
cd <server-path>
git status --short
git diff HEAD
Untracked .claude/ directories are expected (project settings) and should not be flagged as uncommitted changes.
Also check how far behind upstream. Note: this runs git fetch which contacts the remote server — it does not modify local branches but does update remote tracking refs.
cd <server-path>
REMOTE=$(git remote | head -1)
BRANCH=$(git symbolic-ref --short HEAD 2>/dev/null)
if [ -n "$REMOTE" ] && [ -n "$BRANCH" ]; then
git fetch "$REMOTE" 2>/dev/null
BEHIND=$(git log --oneline HEAD.."$REMOTE/$BRANCH" 2>/dev/null | wc -l | tr -d ' ')
echo "Behind upstream: $BEHIND commits"
else
echo "No remote tracking branch configured"
fi
Never pull automatically. Just report the gap.
Overall Check 2 result:
For each local MCP server, run the appropriate audit:
Node.js:
cd <server-path> && npm audit 2>/dev/null
Python:
cd <server-path> && pip audit 2>/dev/null
Combines credential file permissions and gitignore coverage into a single check.
Search for common credential files:
# Google OAuth tokens and credentials
find ~ -maxdepth 4 \( -name "token.json" -o -name "credentials.json" -o -name "application_default_credentials.json" \) 2>/dev/null | grep -v node_modules | grep -v ".Trash"
# Cloud provider credentials
ls -la ~/.aws/credentials 2>/dev/null
ls -la ~/.config/gcloud/application_default_credentials.json 2>/dev/null
ls -la ~/.kube/config 2>/dev/null
ls -la ~/.docker/config.json 2>/dev/null
ls -la ~/.npmrc 2>/dev/null
# SSH keys (skip .pub files — public keys are not secrets)
ls -la ~/.ssh/id_* 2>/dev/null | grep -v '\.pub$'
# Environment files with potential secrets
for dir in ~/Sites ~/projects ~/code ~/repos ~/dev ~/workspace ~/src; do
[ -d "$dir" ] && find "$dir" -maxdepth 3 \( -name ".env" -o -name ".env.local" -o -name ".env.production" \) 2>/dev/null | grep -v node_modules
done | head -50
For each file found, check permissions:
macOS:
stat -f "%Lp %N" <file>
Linux:
stat -c "%a %n" <file>
If any file has permissions looser than 600, ask the user if they'd like to fix it with chmod 600. Apply the change only after user confirmation.
For each credential file found in 4a, check whether it is covered by a .gitignore file:
cd <repo-root> && git check-ignore <credential-file> 2>/dev/null
If the credential file is inside a git repository and not in .gitignore, it could be accidentally committed.
.gitignore coverage — list themgit ls-files <file>)Overall Check 4 result:
Combines global and project-scoped permission review into a single check. Also scans for embedded credentials and accumulated permissions.
Use the Read tool to read ~/.claude/settings.json. Also read ~/.claude/settings.local.json if it exists. If these files were already read earlier in this session (e.g., during Check 2 or from a preceding /local-security:local-setup run), reuse the content rather than re-reading.
For each tool in the permissions.allow array (skip comment lines starting with //):
Write tools at global scope mean Claude can modify external systems from any project without prompting.
Find all project-level settings:
for dir in ~/Sites ~/projects ~/code ~/repos ~/dev ~/workspace ~/src; do
[ -d "$dir" ] && find "$dir" -name "settings.local.json" -path "*/.claude/*" 2>/dev/null | grep -v node_modules
done | sort -u
Read each file using the Read tool (in batches of 3-4). If these files were already read in Check 2 or from a preceding /local-security:local-setup run, reuse the content. For each:
List any MCP write tools permitted
Check for duplicate tools already permitted globally (unnecessary, clutters config)
Flag any tools that seem inappropriate for the project context
PASS: Write tools are project-appropriate
WARN: Duplicates or unexpected write permissions found
Using the settings file content from 5a and 5b, scan all permissions.allow string values for patterns that look like embedded secrets. If settings files were not read in a prior check during this session, read them now using the Read tool before scanning. Do not run any commands — just search the JSON text you already have.
Patterns to look for:
eyJ prefix (base64 JWT)sk-, pk-, key-, token- followed by 20+ alphanumeric charactersBearer followed by a long tokenAuthorization: headers with inline credentialsExample matches in permission entries:
"Bash(curl -H 'Authorization: Bearer sk-abc123...')"
"Bash(API_KEY=eyJhbGciOi... npm run)"
WARN: Credentials baked into bash permission strings are visible in plain text and flow through Anthropic's API during every session. Recommend removing the credential from the permission entry and using environment variables instead.
Using the settings file content from 5b, count the Bash() permission entries per project. Exclude comment lines (starting with //) from the count.
Overall Check 5 result:
For any MCP server registered via uvx or npx (identified in Check 2), check whether the version is pinned. Look at the command and args fields in each server's mcpServers configuration to determine the launch method:
uvx package-name==1.2.3 or npx [email protected]uvx package-name or npx package-nameUnpinned remote servers auto-update on every invocation — a compromised package would execute immediately.
For each credential file found in Check 4, check the modification date:
macOS:
stat -f "%Sm" -t "%Y-%m-%d" <file>
Linux:
stat -c "%y" <file> | cut -d' ' -f1
Note: OAuth refresh tokens auto-renew, so the modification date reflects the last refresh, not the original grant. A recent date means the token is actively being used.
For OAuth tokens, API keys, and environment files:
For SSH keys — these do not auto-renew and are typically rotated on a longer cycle:
PASS: Less than 12 months old
INFO: Older than 12 months — report age, note that SSH key rotation is optional but recommended annually
INFO: Report the age of each credential
Check for environment variables that control data flows:
echo "DISABLE_TELEMETRY=${DISABLE_TELEMETRY:-not set}"
echo "DISABLE_ERROR_REPORTING=${DISABLE_ERROR_REPORTING:-not set}"
echo "DISABLE_BUG_COMMAND=${DISABLE_BUG_COMMAND:-not set}"
echo "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=${CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC:-not set}"
Report:
No PASS/FAIL — this is informational (INFO). Note that all conversation data (including MCP tool results) flows through Anthropic's API for inference.
Check whether a security assessment file exists:
ls -la ~/.claude/security-assessment.md 2>/dev/null
/local-security:local-setup to generate one.If the file exists, read it and check the review log for the most recent entry date. If >30 days old:
Also check for dated snapshots:
ls -la ~/.claude/security-assessments/ 2>/dev/null
Report the number of archived assessments if any exist.
Present a summary table:
SECURITY REVIEW — YYYY-MM-DD
CHECK STATUS
Disk encryption [PASS/WARN/FAIL]
MCP server health [PASS/WARN/FAIL] ([count] local, [count] remote)
Dependency vulnerabilities [PASS/WARN/FAIL]
Credential security [PASS/WARN/FAIL]
Permissions audit [PASS/WARN/FAIL]
Remote server version pin [PASS/WARN/FAIL/INFO]
Stale credentials [PASS/WARN/INFO]
Anthropic data flow [INFO]
Assessment status [PASS/WARN/INFO]
OVERALL: [X passed, Y warnings, Z failures, N informational]
If any FAIL items exist, list recommended actions in priority order.
If all checks pass: "Your setup looks solid. Next review recommended: [date + 1 month]."
If a security assessment file exists (~/.claude/security-assessment.md):
npx claudepluginhub simplefy-ai/local-security --plugin local-securityPerforms security reviews for risky code changes like sensitive file edits, shell commands, dependencies, CI/CD, and secrets using Clawdstrike MCP tools for policy checks.
Audits Claude Code configurations for best practices in skills, instructions, MCP servers, hooks, plugins, security, over-engineering, and context efficiency via file scans and focused checks. Invoke with /claudit [focus-area].
Scans Claude Code .claude/ directory for security vulnerabilities, misconfigurations, and injection risks using AgentShield. Audits CLAUDE.md, settings.json, MCP servers, hooks, and agents.