Cursor 3.24 يطلب التأكيد قبل الحذف الخطير، لكن Run Everything يلتزم الصمت

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

ما الذي تغير في الإصدار 3.24

وفقا لملاحظات إصدارات Cursor، يطلب وضع Auto-review، بدءا من الإصدار 3.24، الإذن قبل عمليات الحذف الخطرة. ويشمل ذلك أربع حالات: الحذف التكراري، والحذف القسري، والحذف باستخدام نمط، والحالة التي قد يكون فيها الهدف الفعلي مختلفا عن الهدف المكتوب في الأمر.

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

أين تغيب الحماية

يعمل وضع Run Everything بطريقة مختلفة. فوفقا لوثائق Cursor، ينفذ الوكيل فيه جميع الأوامر بلا استثناء، ولا توجد بيئة معزولة أو مصنف للمخاطر. ولن تظهر القيود إلا إذا عرّفتها بنفسك في permissions.json.

في جوهر الأمر، يتعلق كل شيء بمفتاح واحد. ما دام مفعلا، فلن يظهر سؤال «هل أنت متأكد؟» إطلاقا، حتى مع أمر يزيل دليلا كاملا. قد يكون ذلك مريحا للتجارب السريعة داخل مستودع مؤقت. أما في مشروع عمل من دون نسخة احتياطية، فهو رهان على ألا يخطئ الوكيل.

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

عادة بسيطة: أنشئ commit قبل التعديل

يقترح كاتب المنشور أمرين. الأول هو إبقاء Auto-review الوضع الافتراضي. والثاني هو إنشاء commit قبل أي تعديل كبير ينفذه الوكيل.

الأمر الثاني مهم بسبب طريقة عمل نقاط الاستعادة في Cursor. فهي تحفظ محليا وبصورة منفصلة عن git. ومهمتها التراجع عن تعديلات الوكيل، لا الاحتفاظ بتاريخ المشروع. التاريخ الدائم لا يعيش إلا في git. لذلك لا يمكن اعتبار نقطة الاستعادة بديلا عن commit: إذا تضرر الدليل نفسه أو بيئة العمل، فلن توجد نقطة رجوع موثوقة إلا داخل المستودع.

عمليا، يكون ترتيب العمل كالتالي:

• قبل إسناد مهمة كبيرة إلى الوكيل، ثبت الحالة الحالية في commit؛
• أبق Auto-review مفعلا، خصوصا في المشاريع التي تحتوي على بيانات مهمة؛
• إذا كنت تستخدم Run Everything، فقلص الصلاحيات في permissions.json؛
• تعامل مع التراجع عبر نقطة استعادة بوصفه وسيلة مريحة، لا بوليصة تأمين.

القيود والسياق

لنكن صريحين: هذه ليست دراسة ولا benchmark، بل ملاحظة قصيرة تستند إلى ملاحظات الإصدار والوثائق. ولا يوضح المنشور بالضبط كيف يعرّف Cursor الحذف «الخطر»، أو مدى موثوقية اكتشافه لجميع الحالات الممكنة. وهذا يعني أنه لا ينبغي الاعتماد كليا على Auto-review أيضا: فهو يقلل المخاطر، لكنه لا يلغي ضرورة الانضباط في إنشاء commits.

المنشور ترويجي جزئيا: فهو يواصل مسلسل الرسوم المتحركة «Vibe Coder and Bug»، الذي تخصص حلقته الخامسة لهذا الموضوع، ويدعو القراء إلى نادي NeyroMakers. ويكشف الكاتب بصورة منفصلة تكلفة الحلقة: نحو 5 دولارات بأسعار API، أي 0.5% من الحد الأسبوعي للاشتراك، إضافة إلى نحو 9 سنتات للتعليق الصوتي عبر ElevenLabs. وقد كتب Claude السيناريو والرسوم المتحركة داخل Claude Code.

الخلاصة

إذا كنت تعمل مع الوكلاء في Cursor، فخصص دقيقة للتحقق من الوضع الذي يعملون فيه. إذا كان Run Everything مفعلا من دون قيود في permissions.json، فقد منحت الوكيل فعليا الإذن بفعل كل شيء. أعد تفعيل Auto-review، واجعل إنشاء commit قبل المهام الكبيرة عادة ثابتة. فهذا إجراء زهيد التكلفة ويحمي من أكثر فئات الأخطاء إزعاجا.