وضع Bypass في Claude Code: لماذا يظهر التأكيد رغم ذلك؟

لماذا يطلب Claude التأكيد حتى في وضع تجاوز الأذونات؟

فهرس المحتويات

1. ما المقصود بـ "Bypass" أصلاً؟
2. السبب الحقيقي: نظام الأذونات ذو الطبقتين
3. الطبقة الأولى: واجهة أذونات الأدوات (قابلة للتحكم بـ Bypass)
4. الطبقة الثانية: الحكم الأمني للذكاء الاصطناعي (غير قابلة للتحكم بـ Bypass)
5. العمليات التي يطلب فيها Claude التأكيد من تلقاء نفسه
6. لماذا طبقتان؟ فلسفة التصميم
7. طرق عملية لتقليل طلبات التأكيد
8. ملخص
الأسئلة الشائعة

لقد ضبطت خيار --dangerously-skip-permissions في Claude Code، غير أن Claude لا يزال يرسل رسائل في المحادثة يسأل فيها "هل يمكنني تنفيذ هذه العملية؟". هل تبدو هذه الحالة مألوفة؟

قد يتبادر إلى ذهنك أن "الـ bypass لا يعمل"، لكن هذا ليس ما يجري. فنظام أذونات Claude Code يتكون من طبقتين مستقلتين، ووضع bypass لا يتحكم إلا في إحداهما.

تتناول هذه المقالة كل شيء، من "ما هو الـ bypass فعلاً" إلى الفرق بين طبقتي الأذونات، وأنواع العمليات التي يطلب فيها Claude التأكيد من تلقاء نفسه، والطرق العملية لتقليل طلبات التأكيد عند العمل بشكل آلي.

1. ما المقصود بـ "Bypass" أصلاً؟

في مجال البرمجيات، يعني "bypass" (التجاوز) تخطي عملية التأكيد أو الموافقة المعتادة والمضي قدماً مباشرةً. تخيّل زر "اشتر الآن" في موقع تسوق الذي يتجاوز شاشة المراجعة — هذا بالضبط تجاوز لتدفق التأكيد.

في وضع Manual في Claude Code (قيمته في الإعدادات default)، تظهر نافذة تأكيد قبل تنفيذ أي تعديل على ملف أو تشغيل أي أمر في الصدفة. لكن منذ Claude Code v2.1.283 تبدأ جلسات الطرفية وVS Code افتراضياً في وضع Auto في كل الخطط ولدى كل المزوّدين، حيث يراجع مصنّف معظم الإجراءات بدلاً من سؤالك (وفي الإصدارات الأقدم كان ذلك في خطط Pro وMax وTeam فقط؛ وإذا عطّل المسؤول وضع auto أو كان النموذج لا يدعمه، تبدأ الجلسة في وضع Manual).

# وضع Manual: تأكيد قبل كل إجراء
$ claude --permission-mode default
> Please fix index.js
[Claude Code] May I edit index.js? → Yes / No

وضع تجاوز الأذونات يتخطى (يتجاوز) تدفق التأكيد هذا.

# وضع Bypass: لا تظهر نوافذ التأكيد تقريباً
$ claude --dangerously-skip-permissions
# أو
$ claude --permission-mode bypassPermissions

لاحظ أن الخيار يتضمن كلمة dangerously (بخطورة). تُحدد Anthropic هذا الوضع بوضوح على أنه مخصص للحاويات أو البيئات المعزولة فقط، وليس موصى به للتطوير المحلي اليومي. للاطلاع على تفاصيل مخاطر وضع bypass، راجع وضع تجاوز أذونات Claude Code: المخاطر والاستخدام الآمن.

إذا ظلت نوافذ التأكيد تظهر كثيراً، فتحقّق أولاً مما إذا كنت تعمل فعلاً في وضع bypass. ما دام الوضع مفعّلاً، يعرض شريط الحالة في الطرفية ⏵⏵ bypass permissions on. وإن لم يظهر ذلك، فهناك سببان شائعان.

كتبته في إعدادات المشروع: تعيين bypassPermissions قيمةً لـ defaultMode في .claude/settings.json أو .claude/settings.local.json لا يسري، وتبدأ الجلسة في وضع Manual (منذ الإصدار v2.1.257). اكتبه في إعدادات المستخدم (~/.claude/settings.json) أو في الإعدادات المُدارة، أو مرّر الخيار عند التشغيل
حاولت التبديل في منتصف الجلسة: لا يمكن اختيار bypass إلا في جلسة فُعّل فيها عند التشغيل. أما في جلسة بدأت من دونه، فلن يصل الضغط على Shift+Tab إلى bypass أبداً

وفضلاً عن ذلك، عندما تبدأ جلسة تفاعلية في وضع bypass لأول مرة، يعرض Claude Code تحذيراً لمرة واحدة يطلب منك تحمّل مسؤولية الإجراءات المنفَّذة دون فحص للأذونات (وتُحفظ موافقتك في إعدادات المستخدم).

2. السبب الحقيقي: نظام الأذونات ذو الطبقتين

الإجابة على سؤال "لماذا يظهر التأكيد حتى مع تفعيل bypass" هي أن نظام أذونات Claude Code مبني على طبقتين مستقلتين.

نظام أذونات Claude Code: البنية ذات الطبقتين

وضع bypass لا يعطّل إلا الطبقة 1 (وحتى فيها تبقى بعض التأكيدات)

الطبقة 1: واجهة أذونات الأدوات قابل للتجاوز غالباً

Tool Permission System

· "هل يمكنني تعديل هذا الملف؟"

· "هل يمكنني تنفيذ هذا الأمر؟"

· "هل يمكنني الوصول لهذا الرابط؟"

· واجهة حوار تأكيد تفاعلية

الطبقة 2: حكم أمان الذكاء الاصطناعي غير قابل للتجاوز

Claude's Own Safety Judgment

· يؤكد قبل العمليات غير القابلة للعكس

· الإنتاج / الإجراءات غير القابلة للتراجع / البيانات الحساسة

· يُرسَل كنص محادثة من Claude

· مدمج في مبادئ سلوك نموذج الذكاء الاصطناعي

‎--dangerously-skip-permissions تعطّل الطبقة 1 كلها تقريباً (تبقى قواعد ask وحذف المسارات الحرجة وقليل غيرها). لا يمكن تجاوز الطبقة 2.

الخلط بين هاتين الطبقتين هو جذر سوء الفهم القائل بأن "الـ bypass لا يعمل". لنستعرض كل طبقة بالتفصيل.

3. الطبقة الأولى: واجهة أذونات الأدوات (قابلة للتحكم بـ Bypass)

الطبقة الأولى هي نافذة التأكيد التي تظهر قبل تنفيذ الأداة — واجهة المستخدم التفاعلية التي تظهر عندما يكون Claude Code على وشك تعديل ملف أو تشغيل أمر في الصدفة.

الأداة	مثال على نافذة التأكيد
تعديل الملف	"هل يمكنني تعديل index.js؟"
تنفيذ Bash	"هل يمكنني تشغيل npm install؟"
الوصول للويب	"هل يمكنني الوصول إلى https://...؟"

هذه بالضبط هي الطبقة التي يعطّلها وضع bypass. عند استخدام --dangerously-skip-permissions، لا تكاد تظهر مثل هذه النوافذ ويمكن لـ Claude تنفيذ الأدوات بحرية. بل إن الكتابة في المسارات المحمية مثل .git و.claude تمرّ دون تأكيد في وضع bypass. بهذا المعنى، يعمل وضع bypass بشكل صحيح.

تأكيدات تظهر حتى في وضع bypass (استثناءات الطبقة 1)

الكلمة المفتاحية هنا هي "تقريباً". تنصّ الوثائق الرسمية على أنّ Claude Code لا يوافق تلقائياً على ما يلي في أي وضع، بما في ذلك bypass (المصدر: صفحة Claude Code الرسمية "Choose a permission mode"، حتى 22 سبتمبر 2026).

الإجراءات المطابقة لقاعدة ask: ما كتبته ضمن permissions.ask في الإعدادات (مثل Bash(git push *)) يطلب التأكيد في كل مرة، حتى في وضع bypass
الأدوات التي تحتاج إلى تدخّلك: أداة AskUserQuestion التي يطرح بها Claude عليك سؤالاً باختيارات، وأدوات MCP المعلَّمة بأنها تتطلب تفاعل المستخدم، وأدوات الموصلات التي ضبطتها مؤسستك على ask
الأمران rm وrmdir الموجَّهان إلى مسارات حرجة: الحذف الذي يستهدف جذر نظام الملفات ومجلداته في المستوى الأول (مثل /usr)، أو المجلد الرئيسي، أو مجلد العمل والمجلدات التي تعلوه. تسمّي الوثائق ذلك "قاطع دائرة" (circuit breaker) يحمي من أخطاء النموذج، ولا تستطيع أي قاعدة allow ولا أي hook الموافقة عليه. غير أنه في تطبيق Desktop وVS Code تُرفض هذه الأوامر فوراً دون طلب تأكيد منذ الإصدار v2.1.309، ويعيد الرفض تلميحات لإعادة كتابة الأمر، وذلك حتى لا تتوقف الجلسات التي لا يكون فيها أحد (سجل التغييرات الرسمي).
غير ذلك: إجراءات حماية تبادل الرسائل بين الجلسات، وأوامر Bash التي تقرأ خارج مجلدات العمل ما دام permissions.blockReadsOutsideWorkingDirectories مفعّلاً

وللقواعد دورها أيضاً. قواعد deny تظل سارية في وضع bypass وتحظر الإجراءات المطابقة. أما قواعد allow فلا أثر لها في وضع bypass (فكل شيء يمرّ أصلاً). وفي التشغيل غير التفاعلي باستخدام -p، تُرفض هذه التأكيدات القليلة بدلاً من انتظار الإدخال.

ملاحظة: هناك 6 أوضاع للأذونات

يمتلك Claude Code ستة أوضاع للأذونات: Manual (default)، وAccept edits (acceptEdits)، وPlan (plan)، وAuto (auto)، وBypass permissions (bypassPermissions)، إضافةً إلى dontAsk الذي لا يظهر أبداً في دورة Shift+Tab ويرفض تلقائياً كل ما كان سيطلب تأكيداً (وهو مخصص لـ CI). يُعدّ وضع bypass (bypassPermissions) الأقل تقييداً. لمعرفة تفاصيل كل وضع، راجع شرح أوضاع الأذونات.

4. الطبقة الثانية: الحكم الأمني للذكاء الاصطناعي (غير قابلة للتحكم بـ Bypass)

الطبقة الثانية هي الحكم الأمني المستقل لـ Claude، وهي منفصلة تماماً عن واجهة تأكيد الأدوات.

عندما يرى Claude أن عملية ما قد تترتب عليها عواقب مهمة، فإنه يرسل رسالة تأكيد في المحادثة كنص عادي. هذا ليس آلية تنفيذ أداة — بل هو السلوك الحواري لـ Claude بوصفه ذكاءً اصطناعياً.

--dangerously-skip-permissions يتخطى نوافذ واجهة الطبقة الأولى، لكنه لا يؤثر على حكم الذكاء الاصطناعي في الطبقة الثانية — لأن الطبقة الثانية مبدأ سلوكي مدمج في نموذج Claude ذاته.

سوء الفهم الشائع

"فعّلت وضع bypass لكن Claude توقف → الـ bypass لا يعمل"
→ الأدق أن تميّز بحسب طريقة توقف Claude. إذا سأل Claude بنص في المحادثة، فالحال: "واجهة الطبقة الأولى معطّلة، لكن الحكم الأمني للطبقة الثانية يطلب التأكيد." وإذا ظهرت في الطرفية نافذة تطلب الإذن، فهي أحد تأكيدات الطبقة 1 التي يُبقيها bypass، مثل قاعدة ask أو حذف مسار حرج. وفي الحالتين يعمل الـ bypass بشكل صحيح (وإن لم تنطبق أي منهما واستمرت التأكيدات، فربما لم تبدأ الجلسة في وضع bypass أصلاً).

لكن الطبقة 2 ليست ضماناً للأمان. فسؤال Claude من عدمه قرار يُتخذ في اللحظة، ولن يتوقف بالضرورة قبل كل إجراء خطير. وتحذّر الوثائق الرسمية أيضاً من أن وضع bypass لا يوفّر أي حماية من حقن الأوامر (prompt injection) أو من الإجراءات غير المقصودة. وما لا يجوز تنفيذه أبداً، فاحظره بقاعدة deny.

5. العمليات التي يطلب فيها Claude التأكيد من تلقاء نفسه

حسب نوع العملية: أي طبقة تتولى التأكيد؟

مقارنة بين الطبقة 1 (واجهة أذونات الأدوات) والطبقة 2 (حكم أمان الذكاء الاصطناعي)

مخاطر عادية (الطبقة 1 فقط)

تعديل الملفات العاديةالطبقة 1 ✓

تنفيذ اختبارات الوحدةالطبقة 1 ✓

← يمكن تعطيلها بالتجاوز

ما يبقى من الطبقة 1 مع bypass

تنفيذ rm -rf على الجذر أو المجلد الرئيسي أو مجلد العملالطبقة 1 !

الإجراءات المطابقة لقاعدة askالطبقة 1 !

أسئلة Claude عبر AskUserQuestionالطبقة 1 !

← تظهر نافذة تأكيد حتى مع التجاوز

مخاطر عالية (الطبقة 2: حكم Claude)

ترحيل قاعدة بيانات الإنتاجالطبقة 2 !

git push --force (الفرع main)الطبقة 2 !

تسريب ‎.env والبيانات الحساسةالطبقة 2 !

← قد يؤكد Claude من تلقاء نفسه حتى مع التجاوز

الطبقة 1: يمكن تعطيلها بالتجاوز استثناءات الطبقة 1: تطلب التأكيد حتى مع التجاوز الطبقة 2: قد يؤكد Claude من تلقاء نفسه

تندرج معايير Claude الداخلية لـ"ينبغي لي التأكيد على هذا" ضمن ثلاث فئات رئيسية.

① عدم القابلية للتراجع

العمليات التي لا يمكن التراجع عنها تجعل Claude أكثر حذراً. الحذف الدائم للملفات، وgit push --force، وDROP TABLE أبرز الأمثلة على ذلك. ولأن الأخطاء يصعب تداركها، يتوقف Claude ويسأل.

② نطاق التأثير

الإجراءات التي تؤثر على بيئات الإنتاج أو عدد كبير من الملفات أو مستخدمين آخرين تستدعي مزيداً من التأكيدات. تغيير ملف محلي واحد نادراً ما يثير سؤالاً؛ أما تعديل مخطط قاعدة بيانات الإنتاج فيكاد يستدعي التأكيد في كل مرة.

③ المخاطر الأمنية

العمليات التي ترسل ملفات .env أو رموز المصادقة أو مفاتيح API إلى الخارج يصنّفها Claude على أنها مخاطر أمنية عالية، فيسأل قبل المضي قدماً.

غير أن بعض عمليات الحذف لا تُترك لحكم Claude أصلاً: الأمران rm وrmdir الموجَّهان إلى مسارات حرجة مثل الجذر أو المجلد الرئيسي أو مجلد العمل نفسه، يوقفهما Claude Code نفسه (الطبقة 1) حتى في وضع bypass (تعرض واجهة سطر الأوامر CLI تأكيداً، بينما يرفضهما تطبيق Desktop وVS Code فوراً منذ الإصدار v2.1.309). وهذا من التأكيدات القليلة التي لا يزيلها bypass.

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

6. لماذا طبقتان؟ فلسفة التصميم

لماذا طبقتان؟ — فلسفة التصميم

فهمها بقياس عامل البناء

القياس: مقاول البناء

🔑 إعطاء مفتاح احتياطي

= منح أذونات الأدوات

❓ المقاول يقرر بنفسه

هل هو جدار حامل؟ هل يجب التأكيد؟

المفتاح (الإذن) ≠ إيقاف حكم المقاول

في Claude Code

‎--dangerously-skip-permissions

وضع التجاوز

= منح أذونات الأدوات

🤖 حكم ذكاء Claude الاصطناعي

← يؤكد بنفسه عند: لا رجعة / إنتاج / سري

الإذن ≠ إيقاف حكم الذكاء الاصطناعي

وضع التجاوز يمنح 'إذن استخدام الأداة' لكنه لا يوقف 'حكم Claude'

إليك تشبيهاً يجعل تصميم الطبقتين سهل الفهم.

تخيّل أنك توظّف مقاولاً لتجديد غرفة وتعطيه مفتاحاً احتياطياً، قائلاً له "يمكنك فعل ما تحتاج إليه". هذا يعادل منح أذونات الأدوات.

لكن عندما يكون المقاول على وشك هدم جدار ويسأل "هل هذا جدار حامل؟ هل أنت متأكد من أنك تريد إزالته؟" — فهو يسأل بناءً على حكمه المهني الخاص، لا لأنه فقد المفتاح.

إعطاؤه المفتاح لا يوقف المقاول عن التفكير. حكمه المهني ووعيه بالسلامة يعملان باستقلالية تامة عن المفتاح.

يعمل Claude بالطريقة ذاتها. وضع bypass يمنح Claude "مفتاح استخدام الأدوات"، لكنه لا يوقف حكم الذكاء الاصطناعي لـ Claude. في الواقع، توقف Claude قبل العمليات عالية المخاطر هو ميزة أمان مقصودة، وليس عطلاً.

7. طرق عملية لتقليل طلبات التأكيد

في مسارات CI/CD وسيناريوهات الأتمتة الأخرى، قد تحتاج إلى أن يُكمل Claude المهام دون توقف. فيما يلي أكثر الأساليب فاعلية.

الأسلوب الأول: استخدام CLAUDE.md لتوفير السياق

أنشئ ملف CLAUDE.md في جذر مشروعك موضحاً فيه البيئة والقيود. عندما يفهم Claude أن "هذه بيئة آمنة معزولة"، تنخفض وتيرة التأكيد بشكل ملحوظ.

# About This Environment

This repository runs inside a CI/CD pipeline test environment.
- Runtime: fully isolated Docker container
- Production impact: none
- All changes are rollback-safe

Please proceed without asking for extra confirmation.

الأسلوب الثاني: إعطاء تعليمات صغيرة ومحددة

التعليمات المبهمة تزيد من حالة عدم اليقين لدى Claude وتثير المزيد من التأكيدات.

نوع التعليمات	مثال	معدل التأكيد
مبهم	"نظّف هذا المشروع"	مرتفع
محدد	"احذف الاستيرادات غير المستخدمة في src/"	منخفض
مبهم	"انشر التطبيق"	مرتفع
محدد	"شغّل npm run deploy:staging على بيئة staging"	منخفض

الأسلوب الثالث: جرّب وضع Auto أولاً

قبل اللجوء إلى وضع bypass الكامل، جرّب وضع auto. يشغّل مصنّف أمان في الخلفية مع الموافقة التلقائية على معظم العمليات، كما يحثّ Claude على مواصلة العمل بدلاً من التوقف لطرح أسئلة استيضاحية (ويظل Claude يسأل عندما يعتمد طلبك أو إحدى المهارات على السؤال). إذا كان سبب استخدامك لـ bypass هو فقط "لقد سئمت من طلبات التأكيد"، فقد يكون وضع auto كافياً. والإجراءات المطابقة لقاعدة ask تظل تطلب التأكيد في وضع auto.

تحذير مهم

لا يمكن لأي إعداد أن يُقلّل حكم Claude الأمني إلى صفر مطلق. هذا أمر مقصود — وليس خطأً أو قيداً. بالنسبة للعمليات عالية المخاطر، يُعدّ طلب Claude للتأكيد سلوكاً صحيحاً. تقبّله باعتباره جزءاً من التصميم. والطبقة 1 أيضاً تُبقي بعض التأكيدات التي لا يزيلها bypass، مثل قواعد ask وحذف المسارات الحرجة.

8. ملخص

العنصر	التفاصيل
ما هو الـ bypass	تخطي نوافذ تأكيد ما قبل الأداة كلها تقريباً (الطبقة الأولى)
ما يعطّله الـ bypass	واجهة أذونات الأدوات ("هل يمكنني تشغيل هذا الأمر؟")، بما في ذلك تأكيدات الكتابة في المسارات المحمية مثل .git و.claude
ما لا يعطّله الـ bypass	الحكم الأمني للذكاء الاصطناعي في Claude (التأكيد المرسل كنص محادثة)، واستثناءات الطبقة 1 (قواعد ask، وrm/rmdir على المسارات الحرجة، وAskUserQuestion)
القواعد في وضع bypass	قواعد deny تظل تحظر، وقواعد allow لا أثر لها
معايير تأكيد Claude	عدم القابلية للتراجع، نطاق التأثير، المخاطر الأمنية
كيفية تقليل التأكيدات	سياق CLAUDE.md / تعليمات محددة / وضع auto
سبب وجود طبقتين	إذن الأداة والحكم الأمني للذكاء الاصطناعي مفهومان منفصلان جوهرياً

عندما يطلب Claude التأكيد حتى في وضع bypass، هذا لا يعني أن الـ bypass توقف عن العمل — بل إن نظامين مستقلين يؤديان دورهما ببساطة. إن فهم هذا الفرق يساعدك على التنبؤ بدقة بسلوك Claude Code واستخدامه بكفاءة أعلى.

لفهم الاختلافات بين منتجات Claude المختلفة، راجع Claude.ai مقابل Claude Code: ما الفرق؟.

الأسئلة الشائعة

هل يمكنني الحصول على صفر تأكيدات مع وضع bypass؟

يمكنك تعطيل نوافذ واجهة تنفيذ الأدوات (الطبقة الأولى) كلها تقريباً، لكن تبقى تأكيدات الإجراءات المطابقة لقاعدة ask، والأمرين rm وrmdir على المسارات الحرجة، والأسئلة عبر AskUserQuestion. كما لا يمكنك القضاء كلياً على تأكيدات الحكم الأمني للطبقة الثانية. هذه ميزة أمان مقصودة. غير أن توثيق بيئتك بعناية في CLAUDE.md وإعطاء تعليمات محددة يمكن أن يُقلّل بشكل كبير من وتيرة سؤال Claude.

هل طلب Claude للتأكيد يُعدّ خطأً تقنياً؟

لا. وضع bypass يتخطى واجهة أذونات الأدوات، لا الحكم الأمني للذكاء الاصطناعي في Claude. توقف Claude قبل العمليات غير القابلة للتراجع أو بيئات الإنتاج أو البيانات الحساسة هو سلوك أمان مقصود — وليس عطلاً. إنه ليس "عدم عمل الـ bypass"، بل "نظامان يعملان باستقلالية." وإذا ظهرت نافذة تطلب الإذن بدلاً من نص في المحادثة، فهي أحد تأكيدات الطبقة 1 التي يُبقيها bypass، مثل قاعدة ask أو حذف مسار حرج.

كيف أمنع Claude من التوقف في مسارات CI/CD؟

ثلاثة أشياء تفيد كثيراً: ① صرّح صراحةً في CLAUDE.md أو system prompt بأن "هذه بيئة CI/CD معزولة تماماً وجميع العمليات تعمل بأمان"، ② أعط تعليمات مهام صغيرة ومحددة (التعليمات المبهمة تثير مزيداً من التأكيدات)، ③ ادمج وضع bypass مع عزل حاوية Docker. وفي ③ شغّل Claude Code بمستخدم غير root: ففي Linux وmacOS يرفض وضع bypass البدء عند التشغيل بصلاحيات root أو عبر sudo. ومع -p تُرفض التأكيدات القليلة التي يُبقيها bypass بدلاً من انتظار الإدخال. وإن أردت ألا يُنفَّذ إلا ما وافقت عليه مسبقاً، فالوثائق الرسمية تذكر أيضاً لبيئات CI الجمع بين --permission-mode dontAsk و--allowedTools. لاحظ أن بعض التوقف قد يظل يحدث حتى مع تطبيق كل ذلك.

هل يمكنني التمييز بصرياً بين نافذة الأداة وتأكيد Claude؟

نعم. تظهر نوافذ أذونات الطبقة الأولى في طرفية Claude Code كواجهة تفاعلية تعرض الأمر أو التعديل مع خيارات مثل Yes وNo. أما تأكيدات الحكم الأمني للطبقة الثانية فتظهر كنص محادثة عادي من Claude (مثل "سيؤدي هذا إلى تعديل قاعدة بيانات الإنتاج — هل أنت متأكد؟"). وما يثير الالتباس هو AskUserQuestion، التي يطرح بها Claude سؤالاً باختيارات: فالسؤال صادر عن Claude، لكنه يظهر في نافذة وينتظر إجابتك حتى في وضع bypass، لأن الطبقة 1 لا توافق عليه تلقائياً أبداً. تنسيق العرض مختلف، لذا يسهل التمييز بينهما بمجرد التعوّد على ذلك.

لماذا يطلب Claude التأكيد حتى في وضع تجاوز الأذونات؟