Configuration

title: कॉन्फ़िगरेशन description: “कॉन्फ़िग फ़ाइल प्रारूप, तीन-स्कोप सिस्टम, और मर्ज नियम” icon: gear

failproofai JSON कॉन्फ़िगरेशन फ़ाइलों का उपयोग करता है यह नियंत्रित करने के लिए कि कौन सी नीतियां सक्रिय हैं, वे कैसे व्यवहार करती हैं, और कहां से कस्टम नीतियां लोड की जाती हैं। कॉन्फ़िगरेशन को आपकी टीम के साथ साझा करना आसान बनाया गया है - इसे अपने रिपॉजिटरी में कमिट करें और हर डेवलपर को समान एजेंट सुरक्षा मिलती है।

कॉन्फ़िगरेशन स्कोप

तीन कॉन्फ़िगरेशन स्कोप हैं, प्राथमिकता क्रम में मूल्यांकित:

स्कोप	फ़ाइल पथ	उद्देश्य
project	`.failproofai/policies-config.json`	प्रति-रिपॉजिटरी सेटिंग्स, संस्करण नियंत्रण में कमिट की गई
local	`.failproofai/policies-config.local.json`	व्यक्तिगत प्रति-रिपॉजिटरी ओवरराइड, gitignored
global	`~/.failproofai/policies-config.json`	सभी प्रोजेक्ट्स में उपयोगकर्ता-स्तरीय डिफ़ॉल्ट

जब failproofai को कोई हुक इवेंट प्राप्त होता है, तो यह वर्तमान कार्यकारी निर्देशिका के लिए मौजूद सभी तीन फ़ाइलों को लोड और मर्ज करता है।

मर्ज नियम

enabledPolicies - सभी तीन स्कोप का यूनियन। किसी भी स्तर पर सक्षम की गई नीति सक्रिय है।

project:  ["block-sudo"]
local:    ["block-rm-rf"]
global:   ["block-sudo", "sanitize-api-keys"]

resolved: ["block-sudo", "block-rm-rf", "sanitize-api-keys"]  ← deduplicated union

policyParams - पहला स्कोप जो किसी दी गई नीति के लिए params परिभाषित करता है पूरी तरह जीत जाता है। किसी नीति के params के भीतर मूल्यों का कोई गहरा मर्जिंग नहीं है।

project:  block-sudo → { allowPatterns: ["sudo apt-get update"] }
global:   block-sudo → { allowPatterns: ["sudo systemctl status"] }

resolved: { allowPatterns: ["sudo apt-get update"] }   ← project wins, global ignored

project:  (no block-sudo entry)
local:    (no block-sudo entry)
global:   block-sudo → { allowPatterns: ["sudo systemctl status"] }

resolved: { allowPatterns: ["sudo systemctl status"] }  ← falls through to global

customPoliciesPaths / customPoliciesPath - पहला स्कोप जो किसी भी रूप को परिभाषित करता है जीत जाता है। disabledCustomPolicies - सभी स्कोप में यूनियन। डैशबोर्ड यहां स्रोत-योग्य आईडी लिखता है जब आप एक स्पष्ट या कन्वेंशन नीति फ़ाइल से व्यक्तिगत नीति को बंद कर देते हैं। सूची में नहीं की गई नीतियां डिफ़ॉल्ट रूप से सक्षम रहती हैं; आईडी में स्रोत फ़ाइल शामिल है ताकि कई फ़ाइलों में समान नाम की नीतियों को स्वतंत्र रूप से नियंत्रित किया जा सके। llm - पहला स्कोप जो इसे परिभाषित करता है जीत जाता है।

कॉन्फ़िग फ़ाइल प्रारूप

{
  "enabledPolicies": [
    "block-sudo",
    "block-rm-rf",
    "block-push-master",
    "sanitize-api-keys",
    "sanitize-jwt",
    "block-env-files",
    "block-read-outside-cwd"
  ],
  "policyParams": {
    "block-sudo": {
      "allowPatterns": ["sudo systemctl status", "sudo journalctl"]
    },
    "block-push-master": {
      "protectedBranches": ["main", "release", "prod"]
    },
    "block-rm-rf": {
      "allowPaths": ["/tmp"]
    },
    "block-read-outside-cwd": {
      "allowPaths": ["/shared/data", "/opt/company"]
    },
    "sanitize-api-keys": {
      "additionalPatterns": [
        { "regex": "myco_[A-Za-z0-9]{32}", "label": "MyCo API key" }
      ]
    },
    "warn-large-file-write": {
      "thresholdKb": 512
    }
  },
  "customPoliciesPath": "/home/alice/myproject/my-policies.js"
}

फील्ड संदर्भ

`enabledPolicies`

प्रकार: string[] सक्षम करने के लिए नीति के नामों की सूची। नामों को बिल्कुल failproofai policies द्वारा दिखाए गए नीति पहचानकर्ताओं से मेल खाना चाहिए। पूरी सूची के लिए Built-in Policies देखें। enabledPolicies में नहीं होने वाली नीतियां निष्क्रिय हैं, भले ही उनके पास policyParams में प्रविष्टियां हों।

`policyParams`

प्रकार: Record<string, Record<string, unknown>> प्रति-नीति पैरामीटर ओवरराइड। बाहरी कुंजी नीति का नाम है; आंतरिक कुंजियां नीति-विशिष्ट हैं। प्रत्येक नीति Built-in Policies में अपने उपलब्ध पैरामीटर प्रलेखित करती है। यदि किसी नीति के पास पैरामीटर हैं लेकिन आप उन्हें निर्दिष्ट नहीं करते हैं, तो नीति के बिल्ट-इन डिफ़ॉल्ट का उपयोग किया जाता है। जो उपयोगकर्ता policyParams कॉन्फ़िगर बिल्कुल नहीं करते हैं वे पिछले संस्करणों के समान व्यवहार प्राप्त करते हैं। किसी नीति के params ब्लॉक के अंदर अज्ञात कुंजियां हुक-फायर समय पर मौन रूप से अनदेखी की जाती हैं लेकिन जब आप failproofai policies चलाते हैं तो चेतावनियों के रूप में फ्लैग किए जाते हैं।

`hint` (cross-cutting)

प्रकार: string (optional) एक संदेश जो तब जोड़ा जाता है जब नीति deny या instruct रिटर्न करती है। Claude को नीति को संशोधित किए बिना कार्यक्षम मार्गदर्शन देने के लिए इसका उपयोग करें। किसी भी नीति प्रकार के साथ काम करता है — बिल्ट-इन, कस्टम (custom/), प्रोजेक्ट कन्वेंशन (.failproofai-project/), या उपयोगकर्ता कन्वेंशन (.failproofai-user/)।

{
  "policyParams": {
    "block-force-push": {
      "hint": "इसके बजाय एक ताज़ी शाखा बनाने का प्रयास करें।"
    },
    "block-sudo": {
      "allowPatterns": ["sudo apt-get"],
      "hint": "sudo के बिना सीधे apt-get का उपयोग करें।"
    },
    "custom/my-policy": {
      "hint": "पहले उपयोगकर्ता से अनुमति माँगें।"
    }
  }
}

जब block-force-push अस्वीकार करता है, तो Claude देखता है: Force-pushing को ब्लॉक किया गया है। इसके बजाय एक ताज़ी शाखा बनाने का प्रयास करें। गैर-स्ट्रिंग मान और खाली स्ट्रिंग्स को मौन रूप से अनदेखी किया जाता है। यदि hint सेट नहीं है, तो व्यवहार अपरिवर्तित है (backward-compatible)।

`customPoliciesPath`

प्रकार: string (absolute path) कस्टम हुक नीतियों वाली JavaScript फ़ाइल का पथ। यह failproofai policies --install --custom <path> द्वारा स्वचालित रूप से सेट किया जाता है (पथ को पूर्ण में हल किया जाता है इससे पहले कि इसे संग्रहीत किया जाए)। फ़ाइल हर हुक इवेंट पर ताज़ी लोड की जाती है - कोई कैशिंग नहीं है। विस्तृत जानकारी के लिए Custom Policies देखें।

कन्वेंशन-आधारित नीतियां

स्पष्ट customPoliciesPath के अलावा, failproofai स्वचालित रूप से .failproofai/policies/ निर्देशिकाओं से नीति फ़ाइलों की खोज और लोड करता है:

स्तर	निर्देशिका	स्कोप
Project	`.failproofai/policies/`	संस्करण नियंत्रण के माध्यम से टीम के साथ साझा किया गया
User	`~/.failproofai/policies/`	व्यक्तिगत, सभी प्रोजेक्ट्स पर लागू

फ़ाइल मिलान: केवल *policies.{js,mjs,ts} से मेल खाने वाली फ़ाइलें लोड की जाती हैं (उदा। security-policies.mjs, workflow-policies.js)। निर्देशिका में अन्य फ़ाइलें अनदेखी की जाती हैं। कोई कॉन्फ़िग की आवश्यकता नहीं: कन्वेंशन नीतियों को policies-config.json में कोई प्रविष्टि की आवश्यकता नहीं है। बस फ़ाइलें निर्देशिका में डालें और वे अगले हुक इवेंट पर उठाई जाती हैं। यूनियन लोडिंग: प्रोजेक्ट और उपयोगकर्ता दोनों कन्वेंशन निर्देशिकाओं को स्कैन किया जाता है। दोनों स्तरों से सभी मिलने वाली फ़ाइलें लोड की जाती हैं (customPoliciesPath के विपरीत जो पहले-स्कोप-जीत का उपयोग करता है)। अधिक जानकारी और उदाहरणों के लिए Custom Policies देखें।

`llm`

प्रकार: object (optional) AI कॉल करने वाली नीतियों के लिए LLM क्लाइंट कॉन्फ़िगरेशन। अधिकांश सेटअप के लिए आवश्यक नहीं है।

{
  "llm": {
    "model": "claude-sonnet-4-6",
    "apiKey": "sk-ant-..."
  }
}

CLI से कॉन्फ़िगरेशन प्रबंधित करना

policies --install और policies --uninstall आदेश आपके एजेंट CLI की हुक सेटिंग्स फ़ाइल (हुक प्रवेश बिंदु) में लिखते हैं, जबकि policies-config.json वह फ़ाइल है जिसे आप सीधे प्रबंधित करते हैं। ये दोनों अलग हैं:

एजेंट CLI सेटिंग्स — एजेंट को प्रत्येक टूल उपयोग पर failproofai --hook <event> कॉल करने के लिए कहता है:
- Claude Code: ~/.claude/settings.json (user), <cwd>/.claude/settings.json (project), <cwd>/.claude/settings.local.json (local)
- OpenAI Codex: ~/.codex/hooks.json (user), <cwd>/.codex/hooks.json (project) — Codex के पास local स्कोप नहीं है
- GitHub Copilot CLI (beta): ~/.copilot/hooks/failproofai.json (user), <cwd>/.github/hooks/failproofai.json (project) — Copilot के पास local स्कोप नहीं है। हुक प्रविष्टियां Copilot के OS-keyed bash/powershell कमांड फील्ड के साथ timeoutSec का उपयोग करती हैं; फ़ाइल में शीर्ष-स्तर version: 1 मार्कर है। Copilot CLI सपोर्ट beta है जबकि हम events.jsonl रिकॉर्ड स्कीमा (जिसे सार्वजनिक दस्तावेज़ निर्दिष्ट नहीं करते) को अधिक वास्तविक-दुनिया सत्रों के विरुद्ध सत्यापित करते हैं। VS Code Copilot Chat agent mode (Preview) हुक कॉन्फ़िग को .github/hooks/*.json, ~/.copilot/hooks/*.json, और ~/.claude/settings.json से पढ़ता है (chat.hookFilesLocations सेटिंग द्वारा शासित) समान Claude-shaped {hookSpecificOutput:{permissionDecision:"deny",…}} अनुबंध का उपयोग करते हुए — बिल्कुल वे पथ जो यह copilot एकीकरण और claude एकीकरण (~/.claude/settings.json) पहले से लिखते हैं, इसलिए failproofai policies --install --cli copilot (या --cli claude) पहले से ही VS Code एजेंट मोड में लागू करता है अलग vscode एकीकरण की कोई आवश्यकता नहीं (VS Code की खोज लॉग्स से पुष्टि की गई)।
- Cursor Agent (beta): ~/.cursor/hooks.json (user), <cwd>/.cursor/hooks.json (project) — Cursor के पास local स्कोप नहीं है। हुक प्रविष्टियां Claude-shaped {type, command, timeout} रूप का उपयोग करती हैं (bash/powershell विभाजन नहीं), लेकिन camelCase event keys (preToolUse, beforeSubmitPrompt, …) के तहत Cursor के hooks schema के अनुसार सपाट सरणी में संग्रहीत। फ़ाइल में शीर्ष-स्तर version: 1 मार्कर है। हैंडलर CURSOR_EVENT_MAP के माध्यम से camelCase → PascalCase को सामान्य बनाता है ताकि मौजूदा बिल्ट-इन नीतियां अपरिवर्तित रूप से फायर हों। Cursor Agent सपोर्ट beta है जबकि हम Cursor के ट्रांसक्रिप्ट ऑन-डिस्क प्रारूप (सार्वजनिक दस्तावेज़ में निर्दिष्ट नहीं) को अधिक वास्तविक-दुनिया इंस्टॉल के विरुद्ध सत्यापित करते हैं।
- OpenCode (beta): ~/.config/opencode/opencode.json + ~/.config/opencode/plugins/failproofai.mjs (user), <cwd>/.opencode/opencode.json + <cwd>/.opencode/plugins/failproofai.mjs (project) — OpenCode के पास local स्कोप नहीं है। अन्य पांच CLIs के विपरीत, OpenCode के पास कोई बाहरी-कमांड हुक सिस्टम नहीं है: यह opencode.json में plugin: [] सरणी के माध्यम से स्पष्ट रूप से पंजीकृत में-प्रक्रिया JS/TS प्लगइन लोड करता है (.opencode/plugins/ से auto-discovery नहीं है कि opencode v1.14.33 पर प्लगइन कैसे लोड होते हैं)। इंस्टॉल एक छोटा जनित प्लगइन शिम डालता है जो failproofai बाइनरी को subprocess-कॉल करता है और बाइनरी की Claude-shape JSON प्रतिक्रिया को प्लगइन शब्दार्थ में वापस अनुवाद करता है: tool-event deny के लिए throw new Error() (टूल कॉल को रद्द करता है), instruct के लिए client.session.prompt(...) AND Stop / SubagentStop deny के लिए (अगले उपयोगकर्ता संदेश के रूप में अस्वीकार कारण जमा करता है — एकमात्र force-retry चैनल क्योंकि session.idle notification-only है और इससे फेंकना एक no-op है), और allow के लिए no-op। शिम both tool names (lowercase → PascalCase via OPENCODE_TOOL_MAP) और tool-input arg keys (camelCase → snake_case via OPENCODE_TOOL_INPUT_MAP for Read / Write / Edit, उदा। filePath → file_path, oldString → old_string) को सामान्य बनाता है बाइनरी को अग्रेषित करने से पहले, तो पथ-जाँच builtins जैसे block-read-outside-cwd, block-env-files, और block-secrets-write OpenCode टूल कॉल पर अपरिवर्तित रूप से फायर करते हैं। सत्र opencode के SQLite DB में ~/.local/share/opencode/opencode.db पर रहते हैं; डैशबोर्ड का सत्र दर्शक opencode db --format json और opencode export <id> के माध्यम से उन्हें पढ़ता है। OpenCode सपोर्ट beta है जबकि हम संस्करणों और अधिक वास्तविक-दुनिया सत्रों के विरुद्ध व्यवहार को सत्यापित करते हैं। OpenCode plugins docs देखें।
- Pi (beta): ~/.pi/agent/settings.json (user), <cwd>/.pi/settings.json (project) — Pi के पास local स्कोप नहीं है। Pi स्टार्टअप पर TypeScript extension packages लोड करता है; सेटिंग्स फ़ाइल एक सपाट स्ट्रिंग सरणी {"packages": ["./relative/path", …]} है। failproofai अपनी bundled pi-extension/ निर्देशिका की ओर इंगित करते हुए एक एकल packages-array प्रविष्टि लिखता है। एक्सटेंशन आंतरिक रूप से Pi के tool_call / user_bash / input / session_start इवेंट्स की सदस्यता लेता है और failproofai --hook <Event> --cli pi को शेल आउट करता है; हैंडलर underscore_lower_snake_case → PascalCase को PI_EVENT_MAP के माध्यम से सामान्य बनाता है ताकि मौजूदा बिल्ट-इन नीतियां अपरिवर्तित रूप से फायर हों। Tool input args भी PI_TOOL_INPUT_MAP के माध्यम से सामान्य बनाए जाते हैं (Pi का Read / Write / Edit path के बजाय file_path प्रदान करता है; शीर्ष-स्तर कुंजी मैपिंग block-env-files और block-secrets-write को फायर करने देता है — block-read-outside-cwd पहले से ही एक path fallback था)। Pi सपोर्ट beta है जबकि Pi के extension API और session-log layout स्थिर होते हैं।
- Hermes (hermes-agent): ~/.hermes/config.yaml (केवल user scope — Hermes के पास project/local कॉन्फ़िग नहीं है)। Hermes एक Slack/Telegram gateway है, इसलिए एक इंस्टॉल हर प्लेटफॉर्म (Slack/Telegram/cli/cron) से टूल कॉल को और आंतरिक subagents को इंटरसेप्ट करता है। हुक प्रविष्टियां एक {command, timeout} जोड़ी हैं (timeout सेकंड में) Hermes के snake_case events (pre_tool_call / post_tool_call / on_session_start / on_session_end / subagent_stop) द्वारा keyed एक hooks: मैप के तहत; हैंडलर events को HERMES_EVENT_MAP के माध्यम से और tool names को HERMES_TOOL_MAP के माध्यम से सामान्य बनाता है ताकि बिल्ट-इन नीतियां अपरिवर्तित रूप से फायर हों। कॉन्फ़िग एक comment-preserving YAML Document round-trip के माध्यम से संपादित किया जाता है ताकि ऑपरेटर की अन्य सेटिंग्स बनी रहें, और install hooks_auto_accept: true सेट करता है ताकि headless gateway (कोई TTY नहीं) सहमति प्रॉम्प्ट के बिना हुक चलाए। मूल्यांकनकर्ता Hermes के {"decision":"block","reason"} stdout अनुबंध को उत्सर्जित करता है (Hermes exit codes को अनदेखी करता है)। सीमाएं: Hermes के पास कोई turn-end Stop इवेंट नहीं है, इसलिए require-*-before-stop builtins इसके लिए कभी नहीं फायर करते हैं (inapplicable, broken नहीं); instruct allow-with-logged-note में degrade होता है (कोई अतिरिक्त-context channel नहीं); और output-secret redaction (sanitize-*) shell-hook अनुबंध पर टूल आउटपुट को फिर से लिख नहीं सकता। Hermes भी एक offline audit स्रोत है — डैशबोर्ड ~/.hermes/state.db से gateway सत्रों को सीधे पढ़ता है।
- OpenClaw (openclaw gateway): ~/.openclaw/openclaw.json (केवल user scope — OpenClaw के पास project/local कॉन्फ़िग नहीं है)। Hermes की तरह, OpenClaw एक स्व-होस्टेड multi-channel gateway है, इसलिए एक इंस्टॉल हर चैनल और अपने आंतरिक subagents से टूल कॉल को इंटरसेप्ट करता है। कार्यान्वयन OpenClaw के in-process plugin hooks के माध्यम से चलता है (इसकी फ़ाइल-आधारित आंतरिक hooks observation-only हैं और ब्लॉक नहीं कर सकते), इसलिए — OpenCode/Pi की तरह — failproofai एक static openclaw-plugin/ पैकेज भेज जो failproofai बाइनरी को async-spawn करता है और verdict को अनुवाद करता है। Install shipped plugin dir को openclaw.json के plugins.load.paths[] में पंजीकृत करता है और इसे plugins.entries.failproofai के तहत सक्षम करता है (hooks.allowConversationAccess: true के साथ, raw-conversation hooks के लिए आवश्यक)। मूल्यांकनकर्ता एक सपाट {permission, reason} verdict को उत्सर्जित करता है और शिम इसे प्रत्येक हुक के native return shape में मैप करता है: before_tool_call → {block:true, blockReason} (PreToolUse), before_agent_run → {outcome:"block", reason} (UserPromptSubmit), और before_agent_finalize → {action:"revise", reason} (Stop — एक वास्तविक turn-end gate, इसलिए require-*-before-stop builtins लागू करते हैं OpenClaw पर, Hermes के विपरीत)। Events और tool names binary-side को OPENCLAW_EVENT_MAP / OPENCLAW_TOOL_MAP (exec→Bash, read→Read, …) के माध्यम से सामान्य बनाते हैं ताकि बिल्ट-इन नीतियां अपरिवर्तित रूप से फायर हों; शिम किसी भी spawn/parse/timeout त्रुटि पर open fail होता है। OpenClaw भी एक offline audit स्रोत है — डैशबोर्ड ~/.openclaw/agents/<agentId>/sessions/<uuid>.jsonl पर इसके JSONL सत्रों को पढ़ता है।
- Factory Droid (droid): ~/.factory/hooks.json (user), <cwd>/.factory/hooks.json (project) — Factory के पास local स्कोप नहीं है। droid एक Claude-style बाहरी-कमांड हुक सिस्टम भेज, लेकिन droid v0.171.0 के विरुद्ध लाइव सत्यापित दो quirks के साथ: (1) event names hooks.json के शीर्ष स्तर पर रहते हैं — कोई "hooks" wrapper नहीं है (droid एक को अस्वीकार करता है); tool events (PreToolUse/PostToolUse) "matcher": "*" ले जाते हैं, non-tool events इसे छोड़ते हैं। (2) Deny को हुक exit code 2 + stderr द्वारा चलाया जाता है, JSON decision नहीं — मूल्यांकनकर्ता की factory branch tool/prompt events के लिए exit 2 रिटर्न करता है और turn-end Stop event पर {decision:"block", reason} केवल (droid का एकमात्र force-retry channel)। Events पहले से ही PascalCase हैं (कोई event map नहीं) और payload Claude snake_case है; केवल tool names FACTORY_TOOL_MAP (Execute→Bash, Create→Write, FetchUrl→WebFetch, …) के माध्यम से सामान्य बनाए जाते हैं। Factory भी एक offline audit स्रोत है — डैशबोर्ड ~/.factory/sessions/<encoded-cwd>/<sessionId>.jsonl पर इसके on-disk JSONL सत्रों को पढ़ता है।
- Devin CLI (devin, Cognition): ~/.config/devin/config.json (user), <cwd>/.devin/config.json (project) — Devin के पास local स्कोप नहीं है। Devin एक pure Claude-clone है devin v3000.1.27 के विरुद्ध लाइव सत्यापित: यह standard Claude "hooks"-wrapper schema (writes merge-preserving हैं ताकि कॉन्फ़िग फ़ाइल की अन्य keys — org_id, theme_mode, … — बनी रहें), पहले से ही-PascalCase event names (कोई event map, कोई handler branch नहीं), और Claude snake_case stdin payload (कोई normalization नहीं) का उपयोग करता है। मूल्यांकनकर्ता की devin branch प्रत्येक event के लिए {"decision":"block","reason"} JSON को stdout पर exit 0 पर अस्वीकार करता है (सत्यापित — block ने --permission-mode dangerous को ओवरराइड किया); turn-end Stop event पर कारण MANDATORY-ACTION force-retry शब्दार्थ ले जाता है ताकि require-*-before-stop builtins लागू हों। केवल tool names DEVIN_TOOL_MAP (exec→Bash; tool_input.command पहले से ही canonical है) के माध्यम से सामान्य बनाए जाते हैं। Devin भी एक offline audit स्रोत है — डैशबोर्ड ~/.local/share/devin/cli/sessions.db पर इसके SQLite सत्रों को पढ़ता है (प्रत्येक sessions row एक वास्तविक working_directory ले जाता है, इसलिए सत्र Devin जैसी project cwd द्वारा समूह)।
- Antigravity CLI (agy): ~/.gemini/config/hooks.json (user), <cwd>/.agents/hooks.json (project) — Antigravity के पास local स्कोप नहीं है। Factory/Devin के विपरीत, Antigravity अपना स्वयं का अनुबंध है (Claude-clone नहीं), agy v1.1.2 के विरुद्ध लाइव सत्यापित। hooks.json एक named-hook schema का उपयोग करता है: शीर्ष-स्तर कुंजी एक हुक नाम है ("failproofai") जिसका मान एक event→handlers map है — tool events (PreToolUse/PostToolUse) handlers को {matcher:"*", hooks:[…]} में लपेटते हैं, जबकि PreInvocation/Stop सपाट handler arrays हैं (अन्य named hooks संरक्षित हैं)। stdin payload camelCase protojson है (toolCall:{name,args}, conversationId, workspacePaths, transcriptPath) — failproofai इसे नीतियां चलाने से पहले snake_case में सामान्य बनाता है, और run_command की PascalCase args (CommandLine/Cwd) को ANTIGRAVITY_TOOL_INPUT_MAP के माध्यम से मैप करता है। मूल्यांकनकर्ता की antigravity branch Antigravity की स्वयं response shapes का उपयोग करता है: {decision:"deny", reason} एक tool/prompt को ब्लॉक करता है (exit 0), {decision:"continue", reason} turn-end Stop पर लूप में फिर से प्रवेश करता है (इसलिए require-*-before-stop builtins लागू करते हैं), और {injectSteps:[{ephemeralMessage}]} PreInvocation पर एक instruction को इंजेक्ट करता है (→ UserPromptSubmit)। Tool names ANTIGRAVITY_TOOL_MAP (run_command→Bash, view_file→Read, …) के माध्यम से सामान्य बनाते हैं। Antigravity भी एक offline audit स्रोत है — डैशबोर्ड ~/.gemini/antigravity-cli/brain/<conversationId>/.system_generated/logs/transcript_full.jsonl पर इसके plain-JSONL transcripts को पढ़ता है (conversation index conversation_summaries.db में)।
- Goose (codename goose, Block): ~/.agents/plugins/failproofai/hooks/hooks.json (user), <cwd>/.agents/plugins/failproofai/hooks/hooks.json (project) — Goose के पास local स्कोप नहीं है। कार्यान्वयन Goose के hooks सिस्टम का उपयोग करता है, cross-agent Open Plugins spec: installer बस failproofai plugin dir को डालता है और Goose स्टार्टअप पर इसे auto-discovers करता है (इसे ~/.config/goose/config.yaml में स्व-पंजीकृत करते हुए)। hooks.json एक Open Plugins schema with एक शीर्ष-स्तर "hooks" wrapper का उपयोग करता है, और matcher हर event पर छोड़ा जाता है — एक bare "*" एक अमान्य regex है जो कुछ से मेल नहीं खाता (goose v1.43.0 के विरुद्ध लाइव सत्यापित)। Event names पहले से ही PascalCase हैं (कोई event map नहीं); stdin payload event/working_dir का उपयोग करता है, जिसे हैंडलर hook_event_name/cwd में सामान्य बनाता है। मूल्यांकनकर्ता की goose branch {"decision":"block","reason"} JSON को stdout पर exit 0 पर अस्वीकार करता है, PreToolUse event पर केवल सम्मानित (goose ≥ v1.37.0 में भेज) — जो shell tool के लिए और delegated subagents के अंदर फायर करता है, इसलिए यह एकमात्र पर्याप्त deny बिंदु है; कोई भी अन्य हुक त्रुटि open fail होती है। Goose के पास कोई Stop event नहीं है, इसलिए require-*-before-stop builtins लागू नहीं होते हैं (Hermes की तरह)। Tool names GOOSE_TOOL_MAP (shell→Bash, write→Write, todo__todo_write→TodoWrite, …) के माध्यम से सामान्य बनाते हैं और path keys GOOSE_TOOL_INPUT_MAP (path/source → file_path) के माध्यम से। Goose भी एक offline audit स्रोत है — डैशबोर्ड ~/.local/share/goose/sessions/sessions.db पर इसके SQLite सत्रों को पढ़ता है (प्रत्येक sessions row वास्तविक working_dir ले जाता है, इसलिए सत्र Devin की तरह project cwd द्वारा समूह; --no-session scratch runs फ़िल्टर किए जाते हैं)।
policies-config.json — failproofai को बताता है कौन सी नीतियों का मूल्यांकन करना है और किन params के साथ (सभी एजेंट CLIs में साझा)

failproofai policies --install --cli codex --scope project
failproofai policies --install --cli copilot --scope project
failproofai policies --install --cli cursor --scope project
failproofai policies --install --cli opencode --scope project
failproofai policies --install --cli pi --scope project
failproofai policies --install --cli hermes --scope user
failproofai policies --install --cli openclaw --scope user
failproofai policies --install --cli factory --scope project
failproofai policies --install --cli devin --scope project
failproofai policies --install --cli antigravity --scope project
failproofai policies --install --cli goose --scope project
failproofai policies --install --cli claude codex copilot cursor opencode pi hermes openclaw factory devin antigravity goose

जब --cli छोड़ा जाता है, तो failproofai पहचानता है कौन से एजेंट CLIs इंस्टॉल किए गए हैं (which claude / which codex / which copilot / which cursor-agent / which opencode / which pi / which hermes / which openclaw / which droid / which devin / which agy / which goose):

एक CLI पहचाना गया — बिना प्रॉम्प्ट किए उस CLI को auto-select करता है।
कई CLIs पहचाने गए इंटरैक्टिव टर्मिनल में — एक arrow-key एकल-select प्रॉम्प्ट दिखाता है एक Detected (N) सेक्शन में समूहीकृत (एक Install for all N detected aggregate row + प्रत्येक detected CLI व्यक्तिगत रूप से) और एक Not installed (M) · install hooks ahead of time सेक्शन हर undetected supported CLI को forward-install विकल्प के रूप में सूचीबद्ध करता है (↑↓ move, Enter select, ^C quit). Uninstall flow केवल Detected सेक्शन दिखाता है।
कई CLIs पहचाने गए non-interactive run में (CI, कोई TTY नहीं) — बिना प्रॉम्प्ट किए सभी detected CLIs के लिए इंस्टॉल करता है।
कोई भी नहीं पहचाना गया — claude पर fallback करता है, एक चेतावनी के साथ कि कोई agent binary PATH में नहीं मिला; हुक कमांड अभी भी लिखा गया है इसलिए यह activate होता है जैसे ही आप एक इंस्टॉल करते हैं।

आप किसी भी समय policies-config.json को सीधे संपादित कर सकते हैं; परिवर्तन अगले हुक इवेंट पर तुरंत प्रभावी होते हैं restart की कोई आवश्यकता नहीं है।

उदाहरण: टीम डिफ़ॉल्ट के साथ प्रोजेक्ट-स्तरीय कॉन्फ़िगरेशन

.failproofai/policies-config.json को अपने रिपॉजिटरी में कमिट करें:

{
  "enabledPolicies": [
    "block-sudo",
    "block-rm-rf",
    "block-push-master",
    "sanitize-api-keys",
    "block-env-files"
  ],
  "policyParams": {
    "block-push-master": {
      "protectedBranches": ["main", "release", "hotfix"]
    }
  }
}

प्रत्येक डेवलपर तब .failproofai/policies-config.local.json (gitignored) को व्यक्तिगत overrides के लिए बना सकता है बिना साथियों को प्रभावित किए।

शुरू करें

मूल अवधारणाएँ

CLI

उपकरण

उन्नत

उदाहरण

title: कॉन्फ़िगरेशन description: “कॉन्फ़िग फ़ाइल प्रारूप, तीन-स्कोप सिस्टम, और मर्ज नियम” icon: gear

कॉन्फ़िगरेशन स्कोप

मर्ज नियम

कॉन्फ़िग फ़ाइल प्रारूप

फील्ड संदर्भ

`enabledPolicies`

`policyParams`

`hint` (cross-cutting)

`customPoliciesPath`

कन्वेंशन-आधारित नीतियां

`llm`

CLI से कॉन्फ़िगरेशन प्रबंधित करना

उदाहरण: टीम डिफ़ॉल्ट के साथ प्रोजेक्ट-स्तरीय कॉन्फ़िगरेशन

​title: कॉन्फ़िगरेशन description: “कॉन्फ़िग फ़ाइल प्रारूप, तीन-स्कोप सिस्टम, और मर्ज नियम” icon: gear

​कॉन्फ़िगरेशन स्कोप

​मर्ज नियम

​कॉन्फ़िग फ़ाइल प्रारूप

​फील्ड संदर्भ

​enabledPolicies

​policyParams

​hint (cross-cutting)

​customPoliciesPath

​कन्वेंशन-आधारित नीतियां

​llm

​CLI से कॉन्फ़िगरेशन प्रबंधित करना

​उदाहरण: टीम डिफ़ॉल्ट के साथ प्रोजेक्ट-स्तरीय कॉन्फ़िगरेशन

title: कॉन्फ़िगरेशन description: “कॉन्फ़िग फ़ाइल प्रारूप, तीन-स्कोप सिस्टम, और मर्ज नियम” icon: gear

कॉन्फ़िगरेशन स्कोप

मर्ज नियम

कॉन्फ़िग फ़ाइल प्रारूप

फील्ड संदर्भ

`enabledPolicies`

`policyParams`

`hint` (cross-cutting)

`customPoliciesPath`

कन्वेंशन-आधारित नीतियां

`llm`

CLI से कॉन्फ़िगरेशन प्रबंधित करना

उदाहरण: टीम डिफ़ॉल्ट के साथ प्रोजेक्ट-स्तरीय कॉन्फ़िगरेशन