Preventing Bad Permissions: Aider and chmod 777

Correction note (2026-10-13). The per-call timings and latency figures that appeared in this article had no benchmark behind them and were removed. Sample output in this article is illustrative, not a recorded run. The only published measurement is p50 0.39 ms and p99 1.91 ms (sigmashake-bench daemon-socket run, 2026-06-10, ssg 0.29.156, n=500). Sub-2 ms evaluation is a design target. ssg eval reads the tool call as JSON on stdin and has no --content, --content-file, --file or positional form.

Correction note (2026-10-13). An earlier version of the rule in this article used the operator MATCHES_REGEX, which the rule DSL does not have, so the rule did not load. The rule now uses REGEX.

Describe the task

You ask Aider to fix a permission error on your application config directory. The agent takes a blunt approach and runs:

chmod 777 /etc/myapp/config

World-writable directories on a production server mean any local process — or any user — can overwrite your config files, inject malicious settings, or escalate privileges. SSG blocks the command before it executes.

# illustrative sample output
[BLOCK] bash › chmod 777 /etc/myapp/config — rule: no-chmod-777

Give SSG context

SSG intercepts Aider's shell tool calls via the SSG MCP Server integration for Aider sessions.

Required context

rule no-chmod-777 {
  enabled true
  priority 95
  severity error
  DENY execution
  IF command STARTS_WITH "chmod 777"
  MESSAGE "World-writable permissions blocked. Use chmod 755 or tighter."
}

Optional context

If you want to block broader patterns (e.g., chmod a+w or chmod o+w), extend the rule:

rule no-world-writable {
  enabled true
  priority 95
  severity error
  DENY execution
  IF command CONTAINS "chmod " AND command CONTAINS "777"
  OR command CONTAINS "a+w"
  OR command CONTAINS "o+w"
  MESSAGE "World-writable permission change blocked."
}

What SSG does

SSG matches the full command string the moment Aider calls the shell tool. The block appears as a tool error with your custom message. Aider typically retries with the correct permissions after reading the message.

Ask the agent to use the right permissions

Send a follow-up message:

chmod 777 was blocked. Use chmod 755 for directories that need to be readable by all users,
or chmod 750 if only the owner and group should have access.

Audit chmod usage across your CI

SSG logs chmod calls, blocked or allowed, on a best-effort basis with the command and the matching rule. Use ssg dashboard to review permission changes applied by any agent across all sessions.

Customize for your permission policy

Your security policy may define a maximum permission octal. Encode it directly:

rule enforce-max-permissions {
  enabled true
  priority 80
  severity warning
  ASK execution
  IF command REGEX "chmod\s+[7][5-7][7]"
  PROMPT "Permission octal exceeds policy threshold. Confirm?"
  MESSAGE "Permission octal exceeds policy threshold. Confirm?"
}

How your rule syntax shapes enforcement

STARTS_WITH "chmod 777" catches the most common form. If agents use octal equivalents or symbolic flags (a+w), add a REGEX condition. Run echo '{"tool":"Bash","input":{"command":"chmod 777 /tmp/test"}}' | ssg eval to verify your pattern fires correctly.

Check the rule against deployment scripts

Some deploy scripts legitimately run chmod 755 on binary files. Make sure your rules only target the 777 case (or whatever your policy defines as dangerous) to avoid blocking valid deploys.