VSCode का SSH एजेंट हैरान करने वाला है

• Fly.io ने VSCode remote SSH editing flow के साथ जुड़ने की कोशिश करते हुए पाया कि VSCode remote shell का हल्का इस्तेमाल करने के बजाय एक अलग agent को install और run करता है
• LLM code generation, execution environment से जुड़े agent loop में ज्यादा उपयोगी होती है, लेकिन यह developer laptop की system settings तक बदल सकती है, इसलिए एक isolated Linux instance की जरूरत होती है
• Emacs का Tramp, SSH जैसे interactive environment में Bourne shell commands चलाकर remote environment तक functionality बढ़ाता है, लेकिन VSCode एक Bash snippet stager से agent और Node binary डाउनलोड करता है
• VSCode agent, port-forwarded SSH के ऊपर चलता है और VSCode frontend से WebSockets connection बनाकर file traversal, arbitrary file editing, shell PTY execution और self-persistence कर सकता है
• सिर्फ development server पर VSCode remote editing की अनुमति देना भी भारी लगता है, और production incident के दौरान अगर यही तरीका इस्तेमाल हो तो चिंता और बढ़ती है, लेकिन Fly Machine के custom connection में इस architecture से बचा जा सका

---

LLM एजेंट लूप के लिए जरूरी isolation

• Fly.io, VSCode के SSH के जरिए remote editing करने वाले flow में integrate होने में रुचि रखता था
  • क्योंकि बहुत से लोग VSCode इस्तेमाल करते हैं, खासकर VSCode forks जो LLM से code generate करते हैं
• LLM-generated code तब उपयोगी होती है जब उसे पता हो कि user क्या कर रहा है, और अगर execution environment के साथ loop बंद किया जा सके तो इसका असर और बढ़ जाता है
  • LLM code generate करता है
  • agent scaffolding code को execute करती है
  • code error पैदा करता है
  • agent error को वापस LLM तक पहुंचाता है
  • यह प्रक्रिया दोहराई जाती है
• यह संरचना hallucination के खिलाफ आधा-अधूरा असरदार antidote हो सकती है, लेकिन developer laptop पर इसे सीधे चलाना जोखिम भरा है
  • LLM, जिस Git project पर काम हो रहा है उसके साथ-साथ system settings को भी बार-बार छू सकती है
• बेहतर तरीका यह है कि तुरंत शुरू होने वाले एक साफ Linux instance में closed-loop agent setup चलाया जाए, और यह सुनिश्चित किया जाए कि वह environment user को नुकसान न पहुंचा सके

VSCode remote SSH agent कैसे काम करता है

• Emacs का Tramp एक तरह से remote editing system का मानसिक पूर्वज कहे जाने लायक Elisp code है
  • यह SSH session जैसे interactive environment से जुड़कर, जहां Bourne shell commands चलाई जा सकती हैं, Emacs की functionality उस environment तक बढ़ा देता है
• VSCode में भी Tramp जैसी capability है, लेकिन यह TypeScript में लिखी गई किसी simplified Tramp संरचना जैसा नहीं है
• remote connection में सिर्फ मौजूदा tools का उपयोग करने के बजाय, VSCode एक Bash snippet stager चलाकर agent डाउनलोड करता है
  • इस agent में Node की binary installation शामिल होती है
  • संबंधित source का संभावित स्थान microsoft/vscode का server/node directory है
• agent, port-forwarded SSH के ऊपर काम करता है और चल रहे VSCode frontend तक WebSockets connection बनाता है
  • इसका subprotocol filesystem में घूम सकता है
  • arbitrary files edit की जा सकती हैं
  • यह अपना shell PTY process चला सकता है
  • यह खुद को persist भी कर सकता है
• security industry में इस तरह काम करने वाले tools के लिए एक नाम है, लेकिन VSCode के साथ अनुचित न हो इसलिए उसे सीधे नहीं कहा गया
• development server पर VSCode remote editing की अनुमति देना असहज लगता है, और production incident के दौरान अगर यही तरीका इस्तेमाल हो तो चिंता और बढ़ जाती है
• Fly Machine के लिए custom connection बनाते समय इस संरचना की चिंता करने की जरूरत नहीं पड़ी, इसलिए लेखक के अनुसार गहरे अर्थ में यह कोई बहुत अहम समस्या नहीं थी

[GN⁺]

Hacker News की राय

• जिस software से 3–4 साल से छेड़छाड़ कर रहे थे, उस पर लगभग एक महीने से लंबा लेख लिखने की कोशिश कर रहे थे, लेकिन Kurt इस बात से बेचैन हो गया कि ब्लॉग पर अगस्त के बाद से कुछ भी पोस्ट नहीं हुआ, इसलिए आखिरकार सबसे सरल लेख लिखने का फैसला किया
  सोच यह थी कि अब तक जो कर रहे थे उसके उलट कम-मेहनत वाला लेख लिखा जाए, और लगा कि 30 मिनट में एक लिख सकते हैं। यह तो बस उस चीज़ को लिख देना था जिससे छेड़छाड़ कर रहे थे, और शायद पढ़ने वालों से कम ही सोचा होगा

  • लेख देखकर अब समझ आया कि यह सचमुच बेतुका ढांचा है, लेकिन सिर्फ ब्लॉग पोस्ट से तुरंत बात समझ नहीं आई। क्योंकि जब agent क्या-क्या कर सकता है, इसकी सूची देखी, तो मान लिया था कि ऐसा दिशा में तो होगा ही नहीं
    README का वाक्य “A compromised remote could use the VS Code Remote connection to execute code on your local machine.” कहीं ज्यादा स्पष्ट था, और इस security advisory के पास CVE नंबर होना चाहिए लगता है
  • HN comment का पहला paragraph अगर एक भी full stop के बिना होता तो शायद और बेहतर पढ़ा जाता। पसंदीदा ब्लॉग अभी भी जिंदा है देखकर अच्छा लगा, और थोड़ी चिंता भी हो रही थी
    अभी दिख रहे पहले दो लेख—McCord-Valim का FLAME-Livebook-GPU लेख और “murid” वाला यह लेख—developer की मानसिक यात्रा को ठीक से दिखाते हैं
  • कम-मेहनत वाले लेख और ज्यादा आने चाहिए
  • समस्या शायद ssh भी हो सकती है। ssh connect करते समय Docker जैसा experience मांगने का कोई तरीका होना चाहिए, और अच्छा होगा अगर यह specify किया जा सके कि किसी खास folder के बाहर processes या file system access रोकने वाली API इस्तेमाल हो
    system binaries की अनुमति भी दी जा सकती है, लेकिन इससे चीजें जटिल हो जाएंगी और VSCode को client में और ज्यादा चीजें ठूंसनी पड़ सकती हैं। मोटे तौर पर खोजने पर ssh server-side chroot options दिखते हैं, लेकिन ssh client manual में इसका खास जिक्र नहीं है
    या फिर समाधान यह हो सकता है कि remote पर Docker container download किया जाए, remote directory mount करके container चलाया जाए, और फिर उस container में ssh से जुड़ा जाए
    सिर्फ subdirectory files sync करने वाले तरीके की समस्या यह है कि VSCode द्वारा शुरू किए गए remote execution और debugging की भी जरूरत होती है। इसलिए plugins को भी remote access चाहिए या उन्हें remote पर चलना होगा, और कुछ code observation अगर local पर चलाए जाएं तो पूरी subdirectory को पहले से sync करने की लागत बहुत ज्यादा हो सकती है
  • “हम बस फिर से ब्लॉग बनने का फैसला कर बैठे। इसलिए हमें यह सीखना पड़ा, और अब आपको भी सीखना होगा” वाला तरीका ही सही रास्ता है

• भोला लग सकता है, लेकिन मुझे ठीक से समझ नहीं आ रहा कि यह security problem क्यों है। अगर आप किसी machine में ssh से connect कर सकते हैं और socket port forwarding कर सकते हैं, तो आपके पास वैसे भी बाकी सब कुछ करने का अधिकार है, और VSCode protocol बस उसे अपने लिए सुविधाजनक तरीके से expose करता दिखता है
  मैं सोच रहा हूं कि क्या security problem यह है कि remote machine वाले ही network में मौजूद, लेकिन SSH अधिकारों के बिना कोई व्यक्ति SSH से forwarded port से connect कर सकता है। user के तौर पर VSCode का SSH system काफी अच्छा काम करता है और मुझे पसंद है

  • फर्क यह है कि VSCode जो करता है, वह ssh command या PuTTY से मिलने वाला SSH session नहीं है
    VSCode target machine पर remote agent install करता है, ssh को transport protocol की तरह इस्तेमाल करता है, और कहता है कि वह उस transport path को user के साथ share करेगा। अगर यह केवल वही काम करे जो चाहिए, तो समस्या नहीं है, लेकिन arbitrary API expose करने वाला agent-based system, ssh के ऊपर terminal की नकल करने वाले परिचित मगर फिर भी पेचीदा तरीके की तुलना में कहीं बड़ा attack surface और risk पैदा करता है
  • मुख्य बात यह है कि agent port-forwarded SSH के ऊपर चलता है और चल रहे VSCode frontend से WebSocket connection बनाता है
    उस connection पर चलने वाला protocol file system में घूम सकता है, arbitrary files edit कर सकता है, अपना shell PTY process शुरू कर सकता है, और खुद को persistent बना सकता है। client से remote server में ssh connect करने का मतलब यह नहीं कि वह server client पर arbitrary code चला सकता है; कम से कम client को स्पष्ट रूप से कोई action लेना होता है
  • मूल रूप से यह बात सही है। यह अपने स्वभाव में vulnerability या security boundary पार करने वाली समस्या नहीं है
    हालांकि जिस अर्थ में “curl | bash” security problem है, उसी अर्थ में यह भी security problem है। और नजदीकी analogy bashrc के अंदर curl | bash हो सकती है
  • development server का agent अब laptop के VS Code में वापस आने वाला reverse vector बन जाता है
    agent network से जुड़ा रहता है और हमेशा चलता है, इसलिए development server firewall का hole सीधे laptop firewall का hole बन जाता है
  • बेशक अधिकार तो पहले से हैं। समस्या यह है कि अब third-party agent उन अधिकारों का इस्तेमाल अपनी मर्जी से कर सकता है, और user को इसका पता नहीं चल सकता

• VSCode कैसे काम करता है, जितना ज्यादा पता चलता है, उतना ही यह duct tape और JavaScript developers के दिमाग में आ सकने वाले सबसे cursed ideas से किसी तरह जोड़ा हुआ लगता है
  सिर्फ SSH extension को ही देखें तो workspace URI format दो तरह के हैं। एक format में व्यावहारिक रूप से सिर्फ hostname होता है, और दूसरा hexadecimal-encoded JSON document format है; दूसरा तब इस्तेमाल होता है जब किसी खास username जैसी अतिरिक्त जानकारी चाहिए हो या hostname में uppercase letters शामिल हों
  इसकी असली जरूरत इसलिए पड़ती है क्योंकि recent workspaces में save होने पर किसी वजह से यह lowercase में बदल जाता है
  SSH connection server पर install किए जाने वाले extension settings को भी support करता है, लेकिन बहुत ज्यादा डाल दें तो Windows host से connect नहीं हो पाता। इन्हें CMD के जरिए command-line arguments के रूप में pass किया जाता है, और CMD में 8191-character limit है, फिर उसी CMD से PowerShell call किया जा रहा है

  • VS Code, Eclipse से बेहतर था। IDE के जरिए SSH की जरूरत कभी नहीं पड़ी, इसलिए उस हिस्से के बारे में नहीं पता; आम तौर पर PuTTY से SSH connect करता था और server पर काम करना हो तो Vi इस्तेमाल करता था
  • JavaScript/TypeScript जानते हों तो editor में custom language support या tools जोड़ना सच में आसान और अच्छा है
    custom autocomplete, diagnostics वगैरह दे सकते हैं, और languages के बीच support के लिए custom Go to definition भी बना सकते हैं
  • duct tape जैसी बात याद दिलाने वाली सबसे दुखद कुछ lines हैं: https://github.com/microsoft/vscode/blob/6dbde2a3ed308f88164...
    अच्छा होगा अगर Microsoft मुझे कुछ महीनों के लिए hire करके किसी कोने में बैठा दे और इस अफरातफरी को सुलझाने दे
  • कचरे और डोरी से बंधी चीज जैसी लगी, इसलिए वापस vim पर लौट गया

• मैंने नेटवर्क, binary exploit और introductory systems programming क्लास के server चलाए हैं, और यह चीज़ बड़ी सिरदर्द है। इस बेवकूफ remote access trojan की वजह से students OpenSSH client इस्तेमाल करना समझ ही नहीं पाते
  इसे ठीक करने के लिए मैंने कुछ चीज़ें आज़माईं। क्लास server के motd में लिखा कि VSCode remote server plugin न इस्तेमाल करें, और क्लास के सामने ncdu /home चलाकर दिखाया कि जिन students का server disk usage 100MB से ऊपर है, वे बिना exception VSCode users हैं
  मैंने user process limit भी 45 पर लगा दी, क्योंकि पता नहीं कैसे VSCode remote access trojan करीब 50 Node processes इस्तेमाल करता है। अगर students motd और क्लास में दी warnings ignore करते, तो limit में फँस जाते, और दोबारा connect करने के लिए उन्हें हमसे processes kill करने को कहना पड़ता
  आखिर में process limit की जगह मैंने एक script लगा दी जो हर 10 सेकंड में सारे .vscode-server remote access trojan को kill कर देती थी

  • इससे university के दिनों की बहुत याद आई, जब हम school system administrator द्वारा network पर लगाए गए पुराने ज़माने जैसे सख्त restrictions को bypass करते थे
  • यह सिर्फ इसलिए नहीं हुआ कि VSCode popular है। 10 साल से भी पहले university में भी ऐसे students थे जो Sublime में SFTP plugin लगाकर इस्तेमाल करते थे, या local पर coding करके FileZilla जैसे GUI client से files transfer करते थे
    जिस class में मैं TA था, उसमें एक assignment था जिसमें basic machine code process करके सीखे गए ISA के assemble/execute tools की नकल करनी थी, और students को hexdump जैसी चीज़ों से file की byte structure समझनी पड़ती थी
    लेकिन Sublime object file को “helpfully” hexdump की text representation की तरह render करता था, readability के लिए spaces जोड़ देता था, और school Linux server पर hexdump करने पर दिखने वाली चीज़ से अलग endian order में दिखाता था
    हर semester कुछ students यह पूछने आते थे कि AD DE EF BE जैसी ASCII string पढ़ने के लिए लिखा code किसी अनजान text को क्यों खोज रहा है, और अक्सर उन्होंने यह verify ही नहीं किया होता था कि actual byte values 0xDE, 0xAD, 0xBE, 0xEF से शुरू होती हैं
  • समझ नहीं आ रहा कि इतना सब क्यों करना पड़ा। VSCode को block करने में बहुत effort लगा, यह पता है, लेकिन VSCode ने specifically क्या problem पैदा की, यह clear नहीं है
  • 50 Node processes—हम हर दिन ईश्वर से और दूर होते जा रहे हैं
  • अगर आप सोच रहे थे कि यहाँ “murid” किसे refer कर रहा है और RAT भी पहली बार सुना है, तो RAT का मतलब Remote Access Trojan है

• मुझे यहाँ alternative ठीक से समझ नहीं आ रहा। VSCode की SSH editing हैरान कर देने वाली तरह से अच्छी चलती है, और remote machine पर vim, nano, micro से जूझना मैंने बहुत पहले छोड़ दिया
  agent बिना disturb किए चुपचाप काम करने देता है। लगभग local machine पर काम करने जैसा feel होता है, और मेरे हिसाब से यह बड़ा फायदा है
  security risk हो सकता है, लेकिन development experience का कोई मुकाबला नहीं। VSCode कौन-से दूसरे editors को खत्म कर रहा है, इसकी मुझे खास परवाह नहीं; बस tool मुझे बिना बाधा काम करने दे

  • alternative TRAMP के सुझाए तरीके के करीब है। मेरी जानकारी में TRAMP remote को execution host नहीं बल्कि network file system की तरह treat करता है
    binaries deploy नहीं करता, pipes के जरिए bytes read/write करता है, और meaningful execution सब local पर होता है। खासकर यह persistence नहीं बनाता; “SSH से connect रहने के दौरान VSCode plugin accessible है” और “VSCode plugin हमेशा accessible है” में फर्क है
  • security risk इस बात से आता है कि unverified plugins को editor पर unlimited access मिल जाता है
  • मेरे अनुभव में, VSCode इस्तेमाल करने वाले colleagues ऐसे तरीकों से constrained होते हैं जिनका उन्हें अहसास भी नहीं होता, और बेहतर तरीका कितना अच्छा हो सकता है इसका उन्हें अंदाज़ा नहीं होता
    कई remotes पर काम करते वक्त उन्हें अक्सर पता नहीं होता कि वे कहाँ connected हैं या connection की state क्या है। terminal धीमा होता है और session state persistence inconsistent होती है
    यह tmux और एक proper text editor इस्तेमाल करने से बहुत खराब experience है। ऊपर से server बहुत heavy है और ठीक से shut down नहीं होता, इसलिए छह-छह server instances चलते रहना भी common है
    updates में से आधे टूट जाते हैं, और actual ssh client से host में जाकर broken vscode server साफ करने का तरीका न जानने के कारण कभी-कभी एक घंटा बर्बाद हो जाता है
  • VSCode exactly कौन-सी features देता है, यह नहीं पता, लेकिन कई remote editing tasks के लिए sshfs काफी अच्छा fit है। basic तौर पर यह VSCode जैसा ही होना चाहिए
  • Emacs का TRAMP भी काफी खराब है, लेकिन फिर भी VSCode remote editing वाली इस अफरातफरी से ज्यादा stable और user-friendly है

• क्या सीखा गया? कि remote code execution मौजूद है? कि development tools पर गलत जगह रखा भरोसा अक्सर पछतावा कराता है? कि आधुनिक software design गड़बड़ है? ज़रा-सी सावधानी बरती होती तो यह सब साफ़ था
  SSH 90 के दशक का समाधान है। यह कुछ features जोड़ा हुआ Telnet है, और इसे “secure” shell कहा जाता है, लेकिन यह शाब्दिक रूप से Telnet+TLS से कम सुरक्षित है
  लोगों ने सोचा कि जब server पर user session वाला tunnel पहले से मौजूद है, तो applications के लिए अलग network transport और secure connection protocol बनाने की ज़रूरत नहीं है; इसलिए उन्होंने SSH के ऊपर तरह-तरह की अजीब लेकिन सराही जाने वाली चीज़ें चढ़ा दीं
  यह distributed operating systems से सीखे गए concepts को छोड़ने, इस बीच विकसित advanced authentication/authorization को नज़रअंदाज़ करने, और सबसे घटिया व आसान चीज़ अपनाने का नतीजा है
  ऐसा “SSH agent” बेतुका नहीं है। हम काम के लिए सही tool बनाने की दिशा में आगे नहीं बढ़े, इसलिए ऐसे मौजूदा tools में लगातार और चीज़ें ठूंसते रहे जो मूल रूप से इस इस्तेमाल के लिए design ही नहीं किए गए थे। हमें हैरान होने का नाटक करने का हक़ नहीं है
  यह वही दुनिया है जो हमने बनाई है। मेहनत से या चुप सहमति से, सबने मिलकर बनाई है। SSH न भी हो तो politics, commerce, schools और बाकी हर चीज़ में भी यही है। हम हर दिन अपने ही बनाए ढेर में रहते हैं, और जिस दिन कुछ नहीं करते, उस ढेर पर एक और फावड़ा मिट्टी डाल देते हैं। हाथ में फावड़ा पकड़े हुए हम यह नाटक नहीं कर सकते कि यह चौंकाने वाला या पागलपन है

  • इसे developers ने नहीं, network security वालों ने बनाया है। अगर HTTPS और ssh के अलावा सभी outgoing ports बंद कर दिए जाएँ, तो आगे सब कुछ HTTPS या ssh के ऊपर tunnel होना ही है
    इसलिए आम तौर पर अगर outgoing HTTPS connections allow करते हैं, तो SMTP को छोड़कर सभी outgoing connections allow करना ही बेहतर है। असली malicious traffic तो वैसे भी HTTPS में tunnel होकर जाएगी, और बचा हुआ असर सिर्फ़ इतना होगा कि tunnel की जटिलता और inefficiency से बचने वाले नए protocols की deployment रुक जाएगी
  • उल्टा, SSH keypair authentication और certificates मेरे हिसाब से authentication के सबसे अच्छे तरीकों में हैं। बिना पहले से setup किए FIDO2 के साथ भी integrate हो जाते हैं
    काश web login भी SSH के तरीके के ज़्यादा करीब होता
  • यह काफ़ी strong conspiracy theory जैसा लगता है। दुनिया की हर चीज़ बुरी नीयत से नहीं चलती; ज़्यादातर लोग दबाव में जो सबसे अच्छा सोच पाते हैं, वही करने की कोशिश करते हैं
    कभी-कभी बाहर जाकर घास छू लेना आत्मा के लिए अच्छा होता है। और यह भी बताइए कि बेहतर SSH protocol कैसे बनाया जाए। constructive criticism के बिना शिकायत बहुत काम की नहीं होती

• यहाँ “SSH agent” term confusing है। आम तौर पर इसका मतलब authentication tokens cache करने वाला daemon होता है

  • सही। VSCode SSH Agent provide नहीं करता, बल्कि local SSH Agent से बात करता है। असल में यह अपना ForwardAgent version है, और उससे जुड़ी security implications भी वैसी ही हैं
    ऊपर से यह तरीका प्रसिद्ध macOS SSH agent को तोड़ देता है: https://github.com/maxgoedjen/secretive/issues/543
  • “SSH Agent” से पहले “VSCode” लगा है, इसलिए distinction काफ़ी ठीक से हो जाती है

• production servers पर vscode remote इस्तेमाल करना पागलपन है, इस पर मैं पूरी तरह सहमत हूँ
  लेकिन बाकी features जिन्हें “बेतुका” बताया गया है, वे expected features जैसे लगते हैं

  • security implications को देखते हुए, मैं सोच रहा हूँ इस feature का use case क्या है। शायद कोई staging instance जो दूसरे environments से काफ़ी अलग-थलग हो

• मैं MAANG में staff engineer तक पहुँचा हूँ, और मुझे लगता है कि यह level सिर्फ़ plain Vim से पाना मुश्किल होता। फिर भी देखता हूँ कि दूसरे high performers भी अब भी Vim या Emacs इस्तेमाल करते हैं
  VCode, JetBrains वगैरह इस्तेमाल करने वाले अच्छे developers भी बहुत हैं, लेकिन barriers to entry खोजने, tools के magic को exploration से खोलने, और पूरी तरह open source व highly hackable community-driven projects को अहमियत देने की प्रवृत्ति इस phenomenon को features या ease of use से बेहतर समझाती है
  VSCode की remote editing कितनी complex है, यह पढ़कर उल्टा VSCode कम इस्तेमाल करने का मन होता है। बस machine में ssh करके उसी machine पर मौजूद editor इस्तेमाल कर लेना चाहिए
  VSCode का solution काम करता है, लेकिन न elegant है, न universally applicable, और टूटने की संभावना भी ज़्यादा है। और Emacs users से माफ़ी, लेकिन Tramp अब भी काफ़ी भयानक है और netrw भी बेहतर नहीं है

  • मैं मानता हूँ कि Tramp शानदार नहीं है, लेकिन एक simple solution है जो बेहतर काम करता है: watchexec + rsync
    आप किसी specific file path को watch कर सकते हैं और सिर्फ़ ज़रूरी चीज़ें exact तरीके से sync कर सकते हैं। आप अब भी local file system पर काम करते हैं, इसलिए editing delay नहीं होता, सारे local tools इस्तेमाल कर सकते हैं, और sync milliseconds में पूरा हो जाता है
    local में delete की गई files को remote में भी delete कराया जा सकता है, और remote machine पर काम खत्म करने के बाद भी आपके पास हमेशा local copy बचती है। Tramp में यही हिस्सा हमेशा manual sync मांगता था। इसके अलावा यह editor-agnostic है
    VS Code का यह feature—अब जब पता है कि यह असल में क्या करता है—बेचैन करता है
  • VSCode-केंद्रित नई team में शामिल होने के बाद मैं काफ़ी सोचता रहा कि अब भी vim को क्यों prefer करता हूँ। हाल की observation यह है कि toolbars और screen भरने वाली दूसरी चीज़ें visually बहुत noisy हैं
    Copilot on किया तो toolbars और बढ़ गए, और जहाँ मैं लिखना चाहता था वहाँ text उड़कर आने लगा। Vim बस code देखने, सोचने और लिखने देता है। VSCode में flow state में जाना मुश्किल है
    मेरी उम्र mid-30s है, college में emacs इस्तेमाल करता था और पहली नौकरी में vim पर switch किया। बहुत उलझे हुए Java project में IntelliJ इस्तेमाल किया, लेकिन बाकी समय vim ही इस्तेमाल करता हूँ
  • hobby के तौर पर coding करते समय tools explore करना और magic को खोलना अच्छा लगता था। अब यह job है, तो VSCode पसंद है। ज़्यादा tinkering नहीं करनी पड़ती और काम खत्म करने पर focus कर सकता हूँ
    complex regex transformations चाहिए हों तभी कभी-कभी vim खोलता हूँ
  • हमारी team के principal engineer और distinguished engineer Vim और Emacs इस्तेमाल करते थे

• मौजूदा remote tools के साथ काम करने के बजाय, VSCode एक comprehensive agent deploy करता है, जिसमें Node.js binary installation, VSCode frontend तक जाने वाला WebSocket connection, और व्यापक system access capabilities शामिल हैं
  इस VSCode agent के पास file system browse करने, files edit करने, shell PTY processes बनाने, और खुद को persistent बनाए रखने तक की क्षमता सहित काफी व्यापक permissions होती हैं

  • स्थानीय रूप से install न किए गए extensions चलाने जैसी VSCode की चीज़ों को support करने का कोई वाजिब alternative साफ़ तौर पर दिखता नहीं। हो सकता है आप ऐसी functionality न चाहें, लेकिन यह product feature set का हिस्सा है
  • यह साफ़ नहीं है कि यह समस्या local VS Code instance की है या remote instance की
    अगर remote की है, तो dependencies के लिहाज़ से elisp Tramp हल्का है, यह समझ आता है, लेकिन मुझे आश्चर्य है कि attack surface सच में इतना अलग है क्या। यानी, पता नहीं remote Node binary के पास ऐसे permissions हैं जो मनमानी ssh commands चलाने वाले user के पास नहीं हैं
    अगर मूल लक्ष्य LLM को एक temporary और disposable virtual machine की सारी चाबियाँ देना था, तो क्या इसका मतलब है कि agent द्वारा खोले गए socket की वजह से वह developer machine भी छू सकता है जिसे isolate करने की कोशिश की गई थी?
  • एक नजरिए से देखें तो ये वे चीज़ें हैं जिन्हें modern operating systems को standard features के रूप में देना चाहिए, और VSCode उन features के न होने की वजह से workaround कर रहा है
    पागलपन जैसा विचार लग सकता है, लेकिन kernel खुद encryption और authentication वाला web server या कोई दूसरा protocol दे सकता है, और eBPF के ज़रिए पूरी machine को सीधे control करने दे सकता है। यह client/server remote control का बिल्कुल अलग paradigm हो सकता है
    बेशक, यह Death Star के निकल जाने जितना बड़ा security hole भी हो सकता है