تصور کنید عامل کدنویسی هوش مصنوعی شما در همین لحظه در حال بازنویسی تاریخچه کامیت‌هایتان است یا در حال نصب درهای پشتی (backdoors) دائمی در سیستم شماست. در حالی که اکثر ابزارهای اجرای موازی عامل‌ها برای ایزوله‌سازی به Git Worktree تکیه می‌کنند، یک بررسی فنی عمیق توسط وب‌سایت fletch.sh که در ۳۰ جولای ۲۰۲۶ منتشر شد، فاش می‌کند که این ابزارها در واقع مرزهای امنیتی واقعی ایجاد نمی‌کنند.
برای توسعه‌دهندگان، Worktree گزینه‌ای بدیهی برای موازی‌سازی به نظر می‌رسد. این قابلیت اجازه می‌دهد تا نسخه دومی از یک مخزن (Repository) را در حدود یک ثانیه باز کنید، بدون اینکه نیاز باشد کل تاریخچه پروژه را مجدداً کپی کنید. این سازوکار توهمی از یک سندباکس (Sandbox) ایجاد می‌کند؛ جایی که یک عامل AI می‌تواند روی یک شاخه ویژگی (Feature Branch) کار کند بدون اینکه دایرکتوری اصلی را به‌هم بریزد. این رویکرد به مدیریت تاریخچه شباهت دارد، اما برخلاف مدل Gitlord که گفتگوهای عامل‌ها را به کنترل نسخه تبدیل می‌کند، در Worktree امنیت ایزولاسیون در اولویت نیست.
با این حال، معماری گیت به این معناست که Worktreeها تقریباً در تمام موارد حیاتی مشترک هستند: رفرنس‌ها (refs)، پیکربندی‌ها (config)، استش‌ها (stashes) و هوک‌ها (hooks). در این ساختار، تنها دایرکتوری کاری (Working Directory)، شاخص (Index) و HEAD ایزوله هستند. هر چیز دیگری در نهایت به دایرکتوری مشترک .git بازمی‌گردد. این موضوع یک حفره امنیتی عظیم برای هر فرآیندی ایجاد می‌کند که یک کاربر انسانی مورد اعتماد نباشد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد کورکورانه به ابزارهای اتوماسیون می‌تواند منجر به نفوذهای گسترده شود. در اینجا، چون دسترسی به قلب مخزن باز است، هر تغییری توسط عامل در لایه‌های مشترک، مستقیماً بر محیط اصلی توسعه‌دهنده اثر می‌گذارد.
سه مسیر اصلی نفوذ و فرار
خطرناک‌ترین آسیب‌پذیری، اجرای کد دلخواه (Arbitrary Code Execution) از طریق هوک‌ها است. بر اساس مستندات فنی این گزارش، چون پوشه‌ی .git/hooks در دایرکتوری مشترک قرار دارد، یک عامل (Agent) که درون یک Worktree فعالیت می‌کند، می‌تواند اسکریپتی را در هوک pre-commit بنویسد. دفعه بعد که شما، به‌عنوان توسعه‌دهنده انسانی، در مخزن اصلی خود یک کامیت انجام دهید، آن اسکریپت با دسترسی کامل سیستم شما اجرا خواهد شد.
فراتر از اجرای کد، عامل‌ها می‌توانند هویت حرفه‌ای شما را دست‌کاری کنند. از آن‌جاکه فایل پیکربندی گیت (git config) مشترک است، اگر یک عامل درون یک Worktree دستور git config user.email را اجرا کند، در واقع پیکربندی مخزن والد (Parent Repository) را تغییر می‌دهد. نتیجه این است که کامیت‌های قانونی و واقعی شما، به ایمیلِ تعریف شده توسط عامل نسبت داده می‌شوند.
تداخل استش‌ها (Stash Interference) سومین نقص بزرگ است. گیت برای هر مخزن تنها یک پشته (Stack) استش نگه می‌دارد. اگر عامل A بخشی از یک کار حیاتی را استش کند، عامل B می‌تواند بدون هیچ هشدار یا هماهنگی، آن استش را در درخت کاری خود Pop کرده و بازیابی کند. این وضعیت منجر به فساد وضعیت (State Corruption) و از دست رفتن داده‌ها بین نویسنده‌های هوش مصنوعی غیرهماهنگ می‌شود. در واقع، این عدم کنترل دقیق روی وضعیت، دقیقاً همان چالشی است که چارچوب‌های GitOps برای کاهش زمان دیباگ عامل‌ها سعی در حل آن دارند.
افسانه «هزینه صفر» در Worktree
بسیاری از سازندگان ابزارها به دلیل این فرض که کپی کردن تاریخچه گران است، از کلون کامل (Full Clone) اجتناب می‌کنند. اما بنچمارک‌های fletch.sh این تصور را رد کردند و نشان دادند که یک کلون محلی از نظر عملکرد و تاثیر بر دیسک، تقریباً با Worktree یکسان است:
- Git Worktree Add: ۸۲۶ میلی‌ثانیه | حدود ۵۸.۷ مگابایت فضای دیسک اضافه شده
- Local Git Clone: ۹۸۲ میلی‌ثانیه | حدود ۵۸.۹ مگابایت فضای دیسک اضافه شده
- Git Clone --shared: ۸۷۰ میلی‌ثانیه | حدود ۵۸.۹ مگابایت فضای دیسک اضافه شده
این اعداد ثابت می‌کنند که شما در هر دو روش، اساساً هزینه Checkout درخت کاری را می‌پردازید. یک کلون محلی در واقع اشیاء (Objects) را کپی نمی‌کند، بلکه آن‌ها را Hardlink می‌کند. این یعنی پوشه‌ی .git ممکن است حجم زیادی را گزارش کند، اما در واقعیت تنها کسری از آن را از فضای دیسک مصرف می‌کند.
چرا راهکارهای موقتی شکست می‌خورند؟
دو تلاش رایج برای «اصلاح» Worktreeها عملاً بی‌اثر هستند. اول، استفاده از extensions.worktreeConfig تنها زمانی کار می‌کند که عامل صراحتاً و به‌طور خاص از فلگ --worktree استفاده کند؛ در غیر این صورت، دستورات استاندارد پیکربندی همچنان به فایل جهانی نشت می‌کنند. دوم، جابه‌جایی هوک‌ها از طریق core.hooksPath یک چرخه باطل (Circular) است، زیرا عامل می‌تواند به‌سادگی آن پیکربندی مشترک را بازنویسی کند تا دوباره به دایرکتوری مخرب خود اشاره کند.
این نقص ساختاری باعث می‌شود Worktreeها برای عامل‌های کانتینری (Containerized Agents) کاملاً نامناسب باشند. برای اینکه به یک کانتینر یک Worktree لینک‌شده بدهید، مجبورید دایرکتوری واقعی .git میزبان را Mount کنید. این اقدام عملاً ایزولاسیون کانتینر را دور می‌زند و اجازه می‌دهد یک پوشه‌ی .git/hooks قابل نوشتن در سمت میزبان، کدی را در خارج از سندباکس اجرا کند. این نقطه ضعف، اهمیت استقرار محیط‌های اجرای کاملاً ایزوله برای عامل‌های کدنویس را بیش از پیش آشکار می‌کند.
تحلیل تحریریه: بهای راحتی
این افشاگری، فرض بنیادی تجربه توسعه‌دهنده در عصر عامل‌ها (Agentic DX) را تغییر می‌دهد. ما امنیت را فدای چند صد میلی‌ثانیه سرعت استارتاپ ادراکی کرده‌ایم. در یک محیط حرفه‌ای، ریسک اینکه یک عامل به‌طور تصادفی دستور git gc را اجرا کند و کامیت‌ها را در Worktreeهای مختلف یتیم (Orphan) کند، بسیار بیشتر از هزینه ناچیز یک کلون مشترک است.
برای کسانی که در حال ساخت IDEهای یکپارچه با AI یا ارکستراتورهای عامل هستند، انتخاب اکنون دوگانه است: یا از Worktree برای یک کاربر انسانی واحد که هر دستور را درک می‌کند استفاده کنید، یا برای هر فرآیند автоном از git clone --shared بهره ببرید. مورد اول یک «راحتی» است، اما مورد دوم یک «الزام امنیتی» است.
اگر در حال حاضر عامل‌ها را به‌صورت موازی اجرا می‌کنید، همین امروز متد ایزولاسیون ابزار خود را بازرسی (Audit) کنید. اگر از Worktree استفاده می‌کند، شما در واقع به یک مدل زبانی بزرگ (LLM) دسترسی نوشتاری به خط لوله‌ی اجرای شل (Shell Execution Pipeline) خود را از طریق هوک‌های گیت داده‌اید.
گام بعدی شما
- اگر از ابزارهای کدنویسی AI استفاده می‌کنید، بررسی کنید آیا از Git Worktree برای مدیریت شاخه‌ها استفاده می‌کنند یا خیر.
- برای هر فرآیند автоном، به‌جای Worktree از دستور
git clone --sharedاستفاده کنید تا مرز امنیتی واقعی ایجاد شود. - دسترسی‌های نوشتن در دایرکتوری
.gitرا برای عامل‌های هوش مصنوعی محدود کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو