Coding agents-க்கு ஏன் Disposable VM பயன்படுத்த வேண்டும்?

உங்கள் மடிக்கணினியை விட disposable VM ஏன் சிறந்தது

ஒரு coding agent-க்கு disposable VM-ஐ வழங்கினால், அது செய்யக்கூடிய மிக மோசமான பாதிப்பு, பத்து நிமிடங்களில் மீண்டும் உருவாக்கக்கூடிய ஒரு இயந்திரத்தை அழிப்பது மட்டுமே. அந்த agent-க்கு root அதிகாரம் கிடைக்கும், அது packages-ஐ நிறுவும், ஒவ்வொரு படிக்கும் அனுமதி கேட்காமல் test suite-ஐ இயக்கும். ஆனால், பாதிப்பு எங்கு நிகழ்கிறது என்பதில் தான் வித்தியாசம் உள்ளது. மடிக்கணினியில், அந்த agent உங்கள் SSH keys, browser profile, .env கோப்புகள் மற்றும் நீங்கள் clone செய்த பிற repositories ஆகியவற்றுடன் ஒரே home directory-ஐப் பகிர்ந்து கொள்கிறது. ஒரு throwaway server-ல், அதற்கு ஒரு shell மற்றும் ஒரு checkout மட்டுமே இருக்கும்; திருடுவதற்கு மதிப்புமிக்க வேறு எதுவும் இருக்காது.

இதுவே முழுமையான வாதம்; இது நிகழ்தகவை விட சமச்சீரற்ற தன்மையைப் பற்றிய வாதமாகும். கவனமாகச் செயல்படும் ஒரு agent, கவனமாகப் பயன்படுத்தப்படும் மடிக்கணினியில் பெரும்பாலும் எந்தப் பாதிப்பையும் ஏற்படுத்தாது. ஆனால், ஒருமுறை தவறு நடந்தால், அதன் விளைவு ஒரு மோசமான commit-ஆக இருக்காது. உங்களிடம் backup இருந்தால், அதிலிருந்து தரவுகளை மீட்டெடுப்பதே அதன் விளைவாக இருக்கும்.

விவாதிக்கும் முன் blast radius-ஐ வரையறுக்கவும்

Blast radius என்பது ஒரு process எட்டக்கூடிய அனைத்தையும் குறிக்கும். உங்கள் சாதாரண user கணக்கில், உங்கள் சாதாரண machine-ல் இயங்கும் ஒரு agent-க்கு, இந்த வரம்பு பெரும்பாலானோர் நினைப்பதை விட பெரியது.

இதில் ~/.ssh/id_ed25519 அடங்கும்; நீங்கள் passphrase-ஐத் தட்டச்சு செய்து சலிப்படைந்ததால் இது பெரும்பாலும் குறியாக்கம் (unencrypted) செய்யப்படாமல் இருக்கும். இதில் ~/.aws/credentials மற்றும் ~/.config/gh/hosts.yml அடங்கும்; இவை வடிவமைப்பிலேயே plain text-ஆக இருப்பவை. ~/code-க்குக் கீழே உள்ள அனைத்து sibling repository-களும் இதில் அடங்கும்; இதில் production connection strings கொண்ட local env file-களும் அடங்கும். நீங்கள் ஒருமுறை paste செய்த tokens-ஐக் கொண்ட உங்கள் shell history-யும் இதில் அடங்கும். உங்கள் laptop இணைக்கப்பட்டுள்ள network-ம் இதில் அடங்கும்; இது பெரும்பாலும் authentication இல்லாத services-ஐக் கொண்ட வீட்டு அல்லது அலுவலக network-ஆகவே இருக்கும்.

இதற்கு எந்தவொரு தீங்கிழைக்கும் agent-ம் தேவையில்லை. நம்பிக்கையுடன் தவறாக இடப்பட்ட ஒரு command போதுமானது. BUILD_DIR அமைக்கப்படாத நிலையில் இயங்கும் rm -rf "$BUILD_DIR"/*, இது /* என விரிவடைந்து, /-ஐ நீக்க மறுக்கும் GNU rm-ன் இயல்புநிலை தடையைத் தாண்டிச் செல்லும். தவறான directory-ல் இயங்கும் ஒரு git clean -xfd, உங்கள் local database-ஐ அழிக்கும் ஒரு docker system prune -af --volumes, அல்லது home directory-ல் தவறுதலாக இயங்கும் ஒரு பயனுள்ள chmod -R 777 என அனைத்தும் இதில் அடங்கும். மற்றவர்களுக்குக் கற்றுக்கொடுத்த அதே இணையத்திலிருந்தே இந்த agent-களும் பயிற்சி பெற்றுள்ளன.

உங்களைக் காக்கும் பொறிமுறை agent-ன் தீர்ப்பு அல்ல. சேதமடைந்தாலும் பரவாயில்லை என்று நீங்கள் கருதும் ஒரு machine-ல் அதை இயக்குவதுதான் உங்களைக் காக்கும்.

செலவு கணக்கீடு சலிப்பானது, அதுவே இதன் நோக்கம்

ஒரு சிறிய VPS-க்கு மாதத்திற்கு சில டாலர்கள் மட்டுமே செலவாகும். ஒரு developer laptop-ஐ மீண்டும் சரிசெய்ய ஒரு நாள் முழுவதுமாகத் தேவைப்படும். இது ஒரு நல்ல சூழல், அதாவது பாதிப்பை நீங்கள் உடனடியாகக் கவனித்து, உங்களிடம் backup-ம் இருக்கும்போது நடப்பது.

உங்கள் சொந்த எண்களைக் கொண்டு இதைக் கணக்கிடுங்கள். உங்கள் ஒரு மணி நேர ஊதியத்தை எடுத்துக்கொள்ளுங்கள். ஒரு operating system-ஐ மீண்டும் நிறுவுதல், home directory-ஐ restore செய்தல், SSH key-ஐ மாற்றுதல், personal access token-ஐ மாற்றுதல் மற்றும் இருபது repositories-ஐ மீண்டும் clone செய்தல் ஆகியவற்றுக்குத் தேவைப்படும் மணிநேரங்களுடன் அதைப் பெருக்குங்கள். இந்தத் தொகையை, உங்கள் provider விற்கும் மிகச்சிறிய server-ன் 12 மாதக் கட்டணத்துடன் ஒப்பிட்டுப் பாருங்கள். பல ஆண்டுகளுக்கு ஒருமுறை ஏற்படும் ஒரு பாதிப்பு கூட, இந்தச் செலவை ஈடுகட்டிவிடும். ஒரு பாதிப்பு பெரிய அளவில் இருக்க வேண்டிய அவசியமில்லை. சிதைந்த local environment-ஐச் சரிசெய்யும் ஒரு மதியப் பொழுது வீணாவதே, அந்த ஆண்டிற்கான server செலவை ஈடுகட்டிவிடும்.

இந்தக் கணக்கீட்டின் இரண்டாம் பகுதி snapshots ஆகும். ஒரு ஆபத்தான செயலைச் செய்வதற்கு முன் எடுக்கப்படும் snapshot, "என் வாழ்க்கையை மீண்டும் மீட்டெடுப்பது" என்ற மோசமான நிலையை, "roll back செய்துவிட்டு வேறு வழியில் முயற்சிப்பது" என்ற எளிமையான நிலைக்கு மாற்றும். நீங்கள் இப்போது பயன்படுத்திக்கொண்டிருக்கும் laptop-ல் இந்த வசதி இல்லை, ஏனெனில் நீங்கள் பயன்படுத்தும் ஒரு கணினியை அதே நேரத்தில் snapshot எடுக்க முடியாது.

அக்டோபர் 2026 நிலவரப்படி தற்போதைய சூழல்

"ஏஜென்ட் (agent) எங்கே இயங்க வேண்டும்" என்ற கேள்விக்கு மூன்று நேர்மையான பதில்கள் உள்ளன. இவை இரண்டு விஷயங்களுக்கு இடையே சமநிலையை ஏற்படுத்துகின்றன: பாதுகாப்பு எல்லை (boundary) எவ்வளவு வலுவானது மற்றும் எவ்வளவு அமைப்புகளை (setup) நீங்கள் பொறுத்துக்கொள்ள முடியும் என்பது.

ஒரு உள்ளூர் micro VM. இந்த வகையைச் சேர்ந்த கருவிகள் உங்கள் சொந்த வன்பொருளில் (hardware) ஒரு உண்மையான மெய்நிகர் இயந்திரத்தை (virtual machine) உருவாக்குகின்றன. அதில் உங்கள் களஞ்சியத்தை (repository) இணைத்து, ஏஜென்ட்டிற்கு root அனுமதியை வழங்குகின்றன. clawk இதற்கு தற்போதைய உதாரணமாகும். இந்த பதிவின் மையக்கருத்தே இதுதான்: கோடிங் ஏஜென்ட்டுகளுக்கு உங்கள் மடிக்கணினியை வழங்காமல், ஒரு தற்காலிக Linux VM-ஐ வழங்குங்கள். அக்டோபர் 2026 நிலவரப்படி, இது Apple silicon-ல் macOS 14 மற்றும் அதற்குப் பிந்தைய பதிப்புகளை இலக்காகக் கொண்டுள்ளது. Firecracker மூலம் Linux-க்கான சோதனை ஆதரவும் உள்ளது. இதை brew install clawkwork/tap/clawk மூலம் நிறுவலாம். ஒரு களஞ்சியத்திற்குள் clawk கட்டளையை இயக்கி sandbox-ஐத் தொடங்கி ஏஜென்ட்டை இணைக்கலாம், clawk down மூலம் அதை நிறுத்தலாம், மற்றும் clawk destroy மூலம் அதை நீக்கலாம். இதன் எல்லை ஒரு hypervisor ஆகும், இது மிகவும் வலுவானது. இதன் குறைபாடு என்னவென்றால், இந்த VM நீங்கள் பயன்படுத்தும் இயந்திரத்திலேயே இயங்குகிறது. எனவே, இது உங்கள் கணினியின் நினைவகத்தைப் (memory) பகிர்ந்து கொள்கிறது மற்றும் நீங்கள் மடிக்கணினியை மூடும்போது இதுவும் நின்றுவிடும்.

ஒரு container. Docker என்பது பெரும்பாலானோர் ஏற்கனவே நிறுவியிருக்கும் ஒரு தீர்வாகும், இது மிகவும் பயனுள்ளது.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm வெளியேறும்போது container-ஐ நீக்கிவிடும், --network none அதற்கு எந்த நெட்வொர்க்கையும் வழங்காது. இது ஒரு build அல்லது test run-க்குச் சிறந்த இயல்புநிலை அமைப்பாகும். இது எதைச் செய்யாது என்பதில் தெளிவாக இருங்கள்: ஒரு container host kernel-ஐப் பகிர்ந்து கொள்கிறது. எனவே, ஒரு kernel bug மூலம் வெளியேற முடியும். நீங்கள் --privileged-ஐச் சேர்த்தாலோ அல்லது /var/run/docker.sock-ஐ mount செய்தாலோ, ஏஜென்ட் "Docker-ஐப் பயன்படுத்த" முடியும் என்பதால் பாதுகாப்பு எல்லை மறைந்துவிடும். Docker socket-ஐ ஒரு container-க்குள் mount செய்வது, அந்த container-க்கு host-ன் root அனுமதியை வழங்குவதற்குச் சமமாகும்.

மீண்டும் உருவாக்கக்கூடிய ஒரு சாதாரண VPS. புதிய கருவிகள் தேவையில்லை, உண்மையான kernel எல்லை உள்ளது, provider snapshots வசதி உள்ளது, மேலும் உங்கள் மடிக்கணினியை அணைத்தாலும் இது தொடர்ந்து இயங்கும். இந்த வழிகாட்டியின் மீதமுள்ள பகுதிகள் இந்த முறையைத்தான் விவரிக்கின்றன. நீண்ட நேரம் இயங்கும் ஏஜென்ட் பணிகளுக்கு இதுவே சிறந்தது, ஏனெனில் நான்கு மணிநேரம் எடுக்கும் ஒரு பணிக்கு, நீங்கள் வீட்டிற்குச் செல்வது எந்தப் பாதிப்பையும் ஏற்படுத்தாது.

VPS மாதிரி: ஏஜெண்டிற்கு எனத் தனி பயனர் கணக்கை உருவாக்குதல்

பாதுகாக்கப்பட்ட server-ல் இருந்து தொடங்கவும். புதிய VPS-ல் முதல் பத்து நிமிடங்கள் என்ற பகுதி, ஏஜெண்ட் சார்ந்தவை அல்லாத அடிப்படைப் பணிகளை விளக்குகிறது: updates, non-root login, key-only SSH, மற்றும் firewall.

அதன்பின், ஏஜெண்டிற்காக மட்டுமே ஒரு கணக்கை உருவாக்கவும். இதன் மூலம், அந்த கணக்கிற்குள் ஏற்படும் பிழைகள் server-ன் பிற பகுதிகளைப் பாதிக்காது.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password என்பது ஊகிக்கக்கூடிய கடவுச்சொல் எதுவும் இல்லை என்பதைக் குறிக்கிறது. நீங்கள் sudo -u agent அல்லது SSH key மூலம் அந்தக் கணக்கை அணுகலாம். agent வேண்டுமென்றே sudo குழுவில் சேர்க்கப்படவில்லை என்பதைக் கவனிக்கவும். sudo வசதி கொண்ட ஒரு ஏஜெண்டிற்கு root அதிகாரம் உண்டு. root பயனரால் மற்ற அனைத்து பயனர்களின் கோப்புகளையும் படிக்க முடியும் என்பதால், நீங்கள் உருவாக்கிய இந்தத் தனிமைப்படுத்தல் வெறும் பெயரளவில் மட்டுமே இருக்கும். ஏஜெண்டிற்கு மென்பொருள் தொகுப்புகளை (packages) நிறுவ வேண்டிய அவசியம் இருந்தால், அதற்குத் தனி server-ஐப் பயன்படுத்துவதே சிறந்தது; மாறாக, பகிரப்பட்ட server-ல் அதற்கு sudo அதிகாரத்தை வழங்கக்கூடாது. பொதுவான விதிகள் VPS-ல் Linux பயனர்களுக்கான குறைந்தபட்ச அதிகாரம் (least privilege) என்ற பகுதியில் உள்ளன.

அதை நம்புவதற்கு முன் எல்லையைச் சரிபார்க்கவும். agent பயனராக, உங்கள் சொந்த கணக்கின் home directory-ஐப் பட்டியலிட முயற்சிக்கவும்:

sudo -u agent ls /home/you

நீங்கள் ls: cannot open directory '/home/you': Permission denied என்பதைப் பார்க்க வேண்டும். அதற்குப் பதிலாகக் கோப்புகளின் பட்டியல் தெரிந்தால், உங்கள் home directory-ஐ மற்ற பயனர்களும் படிக்க முடியும் என்று அர்த்தம். அப்போது, தனித்தனியாகப் பூட்டப்படாத கோப்புகளை (உதாரணமாக, world-readable .env கோப்பு) ஏஜெண்டால் படிக்க முடியும். இதைச் சரிசெய்ய sudo chmod 700 /home/you கட்டளையைப் பயன்படுத்தவும். இந்தச் சோதனை உங்கள் தனிப்பட்ட SSH key-ஐப் பாதுகாப்பதற்கானது அல்ல; பிற பயனர்கள் அணுகக்கூடிய private key கோப்பை ssh நிராகரித்துவிடும். எனவே, நீங்கள் பயன்படுத்தும் எந்தவொரு key-ம், உங்கள் home directory-ன் mode எதுவாக இருந்தாலும், agent பயனரால் படிக்க முடியாத நிலையிலேயே இருக்கும்.

நற்சான்றிதழ்களை (credentials) அந்த இயந்திரத்தில் சேமிக்க வேண்டாம்

நீங்கள் ஒரு தற்காலிக இயந்திரத்தைப் பயன்படுத்தும் நோக்கமே, அதில் உங்கள் production ரகசியங்களை நகலெடுத்தால் வீணாகிவிடும். விதி எளிதானது: அந்த இயந்திரத்தில் உள்ள எந்தவொரு நற்சான்றிதழும், இன்று மதியமே அதை மாற்ற வேண்டிய சூழல் ஏற்பட்டாலும் உங்களுக்குப் பாதிப்பை ஏற்படுத்தாததாக இருக்க வேண்டும்.

Git-க்கு, உங்கள் SSH key-ஐ நகலெடுப்பதற்குப் பதிலாக, SSH agent-ஐ forward செய்யுங்கள். Private key உங்கள் மடிக்கணினியிலேயே இருக்கும்; கையொப்பமிடுவதற்கான கோரிக்கைகள் (signature requests) மட்டுமே இணைப்பின் வழியாகச் செல்லும்.

ssh -A agent@203.0.113.10
ssh -T git@github.com

இரண்டாவது கட்டளை Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. என்பதற்குப் பதிலளிக்க வேண்டும். சர்வரில் எந்தவொரு key கோப்பும் இல்லாமலேயே git push வேலை செய்யும் என்பதை இது உறுதிப்படுத்துகிறது. அதன் பிறகு அந்த இயந்திரத்தில் ls -la ~/.ssh-ஐ இயக்கி, அதில் எந்தவொரு private key-யும் இல்லை என்பதை உறுதிப்படுத்தவும்.

Agent forwarding-ல் ஒரு முக்கியமான எச்சரிக்கை உள்ளது, அதைத் தெளிவாகக் கவனிக்கவும்: நீங்கள் இணைப்பில் இருக்கும்போது, அந்த சர்வரில் root அனுமதி உள்ள எவரும், அந்த forwarded socket-ஐப் பயன்படுத்தி உங்களைப் போலவே அங்கீகாரம் (authenticate) பெற முடியும். நீங்கள் மட்டுமே பயன்படுத்தும் சர்வரில் இது ஏற்றுக்கொள்ளக்கூடிய ஒரு சமரசம். ஆனால், பகிரப்பட்ட சர்வரில் இது பாதுகாப்பானது அல்ல; அத்தகைய சூழலில், ஒரு குறிப்பிட்ட repository-க்கு மட்டும் வரையறுக்கப்பட்ட deploy key-ஐப் பயன்படுத்துவதே சிறந்த தீர்வாகும். இதற்கான தேர்வுகள் SSH key management basics பகுதியில் விளக்கப்பட்டுள்ளன.

API keys-க்கு, அந்த agent-க்கு எனத் தனிப்பட்ட key-ஐ உருவாக்கி, அதற்குச் செலவு வரம்பை (spending limit) நிர்ணயிக்கவும். அதை agent பயனர் உரிமையுள்ள, 600 mode-ல் உள்ள கோப்பில் சேமிக்கவும். இயந்திரத்தை அழிக்கும்போது, அந்த key கசிந்ததா என்று கவலைப்படுவதற்குப் பதிலாக, அதை உடனடியாக ரத்து (revoke) செய்துவிடவும். ஒவ்வொரு key-க்கும் எவ்வளவு செலவாகிறது என்பதைக் கண்காணிப்பதன் மூலமே AI agent cost control on a VPS பகுதியில் உள்ள எண்களைக் கணிக்க முடியும்.

ஏஜென்ட் நெட்வொர்க்கில் அணுகக்கூடியவற்றை கட்டுப்படுத்துதல்

Filesystem isolation என்பது எல்லையின் ஒரு பகுதி மட்டுமே. மற்ற பகுதி egress ஆகும்: ஒரு process எதனுடன் தொடர்பு கொள்ள அனுமதிக்கப்படுகிறது என்பதே அது. Linux-ல் ஒரு process-ஐ உருவாக்கிய பயனரை வைத்து வெளிச்செல்லும் traffic-ஐ வடிகட்ட முடியும்; இது இந்த முறைக்கு சரியாகப் பொருந்தும்.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

விதிகள் வரிசையாக வாசிக்கப்படுகின்றன, எனவே இறுதி REJECT முந்தைய வரிகள் அனுமதிக்காத அனைத்தையும் தடுத்துவிடும். இதை ஏஜென்ட் பயனர் மூலம் சோதிக்கவும்:

sudo -u agent curl -sS -m 5 http://example.com

இது உடனடியாக ஒரு curl: (7) Failed to connect to example.com பிழையுடன் தோல்வியடைய வேண்டும், அதைத் தொடர்ந்து உங்கள் curl பதிப்பிற்கு ஏற்ப மாறுபடும் வாசகங்கள் வரும். ஏனெனில், connection-ஐத் தாமதப்படுத்தாமல், இந்த reject விதி உடனடியாகப் பதிலளிக்கிறது. அதே host-க்கு செய்யப்படும் HTTPS கோரிக்கை தொடர்ந்து வெற்றிபெற வேண்டும்.

இரண்டு முக்கியமான வரம்புகள் உள்ளன. முதலாவதாக, sudo apt install -y iptables-persistent மற்றும் sudo netfilter-persistent save மூலம் சேமிக்காவிட்டால், அடுத்த reboot-ல் இந்த விதிகள் அழிந்துவிடும். இரண்டாவதாக, இது ports மற்றும் addresses-ஐ மட்டுமே வடிகட்டுகிறது, பெயர்களை அல்ல. Port 443-ஐ அனுமதிக்கும் ஒரு விதி, இணையத்தில் உள்ள அனைத்து HTTPS host-களையும் அனுமதிக்கிறது; இது model API-ஐ அணுக போதுமானது, அதே சமயம் ஒரு pastebin-ஐ அணுகவும் போதுமானது. ஒரு உண்மையான domain allow-list-க்கு, கோரப்பட்ட hostname-ஐ வாசிக்கும் ஒரு proxy வழியாக traffic செல்ல வேண்டும்; இது பெரும்பாலான தனிப்பட்ட developer அமைப்புகளுக்குத் தேவையானதை விட அதிகப்படியான கட்டமைப்பாகும். உங்களிடம் உள்ளதை மட்டும் உறுதிப்படுத்திக் கொள்ளுங்கள்: நீங்கள் இழக்கத் தயாராக இருந்த ஒரு machine-ல், port-அளவிலான egress கட்டுப்பாடு மட்டுமே உங்களிடம் உள்ளது.

பணிகளுக்கு இடையே சுத்தமான நிலைக்கு திரும்புதல்

ஒவ்வொரு பணிக்கும் ஒரு சுத்தமான நிலையைப் பராமரிப்பது கவனிக்கப்படாத ஒரு நன்மையாகும். முந்தைய டிக்கெட்டில் மூன்று மணிநேரம் செலவிட்ட ஒரு agent, நிறுவப்பட்ட packages, பாதியில் நின்ற migrations, பழைய node_modules, மற்றும் யாரும் சரிபார்க்காத மாற்றங்களைக் கொண்ட git working tree ஆகியவற்றை விட்டுச் செல்கிறது. அடுத்த பணி இவை அனைத்தையும் அப்படியே பெற்றுக்கொள்கிறது; எந்தக் குழப்பம் எந்த run-க்கு உரியது என்பதைக் கண்டறியவே உங்கள் review நேரம் வீணாகிறது. ஒரு குறுகிய நோக்கமுடைய agent குறைந்த அளவிலான மாற்றங்களையே உருவாக்குகிறது. எனவே, ஒரு disposable machine-ஐ குறைந்தபட்ச மாற்றங்களைச் செய்யும் திறன் கொண்ட ஒரு கருவியுடன் இணைப்பது, diff மற்றும் எஞ்சியிருக்கும் கோப்புகளைச் சரிபார்க்கும் அளவுக்குச் சிறியதாக வைத்திருக்க உதவுகிறது.

இதற்கான எளிமையான வழி, ஒவ்வொரு பணிக்கும் ஒரு புதிய checkout-ஐ உருவாக்குவதாகும்.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

இதன் வலுவான வடிவம், machine அமைக்கப்பட்ட பிறகு, எந்த agent-ம் அதைத் தொடுவதற்கு முன்பாக எடுக்கப்படும் provider snapshot ஆகும். அந்த snapshot-ஐ மீண்டும் பதிவேற்றுவது, packages உட்பட முழு அமைப்பையும் ஒரு தெரிந்த நிலைக்குக் கொண்டு வரும். பெரும்பாலான providers இதை control panel மூலமாகவோ அல்லது API மூலமாகவோ வழங்குகிறார்கள்; இது machine-க்குள் இயக்கும் command அல்ல. எனவே, இதற்கான துல்லியமான வழிமுறைகள் உங்கள் provider-ஐப் பொறுத்தது. machine சாதாரணமாக இருக்கும்போதே snapshot எடுப்பதே சிறந்த நடைமுறை.

உங்களுக்குத் தேவையான எதையும் இந்த disposable machine-ல் வைக்காதீர்கள்; அதாவது, கிளைகளை (branches) உள்ளூரில் சேமித்து வைப்பதற்குப் பதிலாக, அவற்றை உடனுக்குடன் push செய்யுங்கள். ஒருவேளை அந்த machine-ல் நீங்கள் இழக்க விரும்பாத தரவுகள் இருந்தால், restic backups on a VPS மூலம் முறையாக backup எடுங்கள். ஒரு machine-ஐ அழிப்பது எவ்வித பாதிப்பையும் ஏற்படுத்தாது என்ற நிலை இருந்தால் மட்டுமே, அதைத் தாராளமாகப் பயன்படுத்த முடியும்.

பல servers-க்கு பணம் செலுத்தாமல் பல தனித்தனி சூழல்களை (isolated environments) உருவாக்க விரும்பினால், ஒரு பெரிய VPS-ல் நேரடியாக guest VM-களை இயக்கலாம். Nested virtualisation on a VPS என்பது இது எவ்வாறு செயல்படுகிறது என்பதையும், உங்கள் provider இதை அனுமதிக்கிறதா என்பதை எவ்வாறு சரிபார்ப்பது என்பதையும் விளக்குகிறது. இந்தத் தனிமைப்படுத்துதல் இருபுறமும் செயல்படும்; ஒரே machine-ல் உள்ள இரண்டு agents ஒன்றையொன்று பிரிந்து செயல்படுவதற்குப் பதிலாக, அவற்றுக்கிடையே ஒருங்கிணைப்பு தேவைப்பட்டால், one Claude Code session can send text straight to another என்பதைப் பயன்படுத்தி, ஒவ்வொரு handoff-ஐயும் உங்கள் வழியாக அனுப்பாமல் நேரடியாகத் தொடர்புகொள்ளச் செய்யலாம்.

மடிக்கணினியை கவனமாகப் பயன்படுத்தும்போது அது போதுமானதாக இருக்கும் சூழல்

இதைப் பற்றி வெளிப்படையாக இருங்கள், ஏனெனில் தனிமைப்படுத்துதலை (isolation) மிகைப்படுத்திக் கூறுவது மக்கள் இதைக் கேட்பதை நிறுத்திவிடச் செய்யும்.

ஒவ்வொரு கட்டளையையும் (command) இயக்கும் முன் நீங்கள் சரிபார்க்கிறீர்கள் என்றால், மடிக்கணினி போதுமானது. அனுமதி கோரும் prompt ஒரு உண்மையான கட்டுப்பாட்டு கருவியாகும், மேலும் server-ல் Claude Code-ஐ பாதுகாப்பாக இயக்குவது என்பது அதன் ஒவ்வொரு நிலையும் எதைத் தடுக்கிறது என்பதை விளக்குகிறது. உங்கள் பணி ஒரு தனி repository-ஆக இருந்து, அந்த இயந்திரத்தில் production credentials எதுவும் இல்லை என்றால், பாதிப்பு ஏற்படும் எல்லை (blast radius) ஏற்கனவே சிறியதாகவே இருக்கும். உங்கள் agent sessions குறுகிய காலமாகவும், உங்கள் கண்காணிப்பிலும் இருந்தால், ஆபத்துக்கான கால அவகாசமும் குறைவாகவே இருக்கும்.

நீங்கள் prompt-களைத் தவிர்க்கத் தொடங்கும் தருணத்தில் இந்த நிலைமை மாறுகிறது. auto mode என்பது Claude Code-ன் இயல்புநிலை (default) என்பதும், புதிய நிறுவலின் போது கோப்புகளைத் திருத்துவதற்கு அல்லது கட்டளைகளை இயக்குவதற்கு முன்பு அது உங்களிடம் அனுமதி கேட்பதில்லை என்பதும் கவனிக்கத்தக்கது. கவனிக்கப்படாத செயல்பாடுகள் (unattended runs), இரவு நேரப் பணிகள் மற்றும் ஒரு திட்டத்திற்கு ஒப்புதல் அளித்துவிட்டு நீங்கள் விலகிச் செல்லும் எந்தவொரு பணிப்பாய்வும் (workflow), கட்டுப்பாட்டை உறுதி செய்த மனிதச் சரிபார்ப்பை நீக்கிவிடுகின்றன. அந்தச் சூழலில், இயந்திரமே அதைக் கட்டுப்படுத்த வேண்டிய கட்டாயம் ஏற்படுகிறது. இதுவே agent-ன் அணுகல் எல்லையை விரிவுபடுத்தும் எதற்கும் பொருந்தும், இதில் ஒரே நேரத்தில் பல repositories-ல் coding agent-ஐ VPS-ல் இயக்குவதும் அடங்கும்.

இந்த முடிவு, நீங்கள் அந்த model-ஐ எவ்வளவு நம்புகிறீர்கள் என்பதைப் பற்றியது அல்ல. அந்த model தவறு செய்யும்போது, அதன் அருகில் என்ன பாதுகாப்பு உள்ளது என்பதைப் பற்றியது.

FAQ

Coding agent-க்கு container isolation போதுமானதா?

பெரும்பாலான பணிகளுக்கு, ஆம், இரண்டு நிபந்தனைகளுக்கு உட்பட்டு. Container-ஐ --privileged உடன் இயக்கக்கூடாது, மேலும் அதில் /var/run/docker.sock-ஐ mount செய்யக்கூடாது. ஏனெனில் இவை இரண்டில் எது இருந்தாலும், process-க்கு host-ன் root-ஐ அணுக வழி கிடைத்துவிடும். Container-கள் host kernel-ஐப் பகிர்ந்துகொள்வதால், virtual machine-ஐ விட இதன் பாதுகாப்பு எல்லை பலவீனமானது. இணையத்திலிருந்து பெறப்பட்ட நம்பகத்தன்மையற்ற குறியீட்டை (untrusted code) agent இயக்குகிறது என்றால், ஒரு உண்மையான VM அல்லது தனி server-ஐப் பயன்படுத்துவது சிறந்தது.

Server-ல் agent-க்கு sudo தேவைப்படுமா?

தேவையில்லை. Sudo அனுமதி வழங்கினால், நீங்கள் உருவாக்கிய isolation பயனற்றுப் போய்விடும், ஏனெனில் root பயனர் அந்த machine-ல் உள்ள மற்ற அனைத்து கணக்குகளையும் படிக்க முடியும். Sudo இல்லாத ஒரு agent பயனரை உருவாக்கி, அவருக்குத் தேவையான பணி அடைவுக்கு (work directory) மட்டும் எழுதும் உரிமையை (write access) வழங்கவும். ஒரு பணிக்குக் கண்டிப்பாக package installation தேவைப்பட்டால், அந்த agent-க்கு ஒரு தனி machine-ஐ வழங்கவும்; மாறாக, பகிரப்பட்ட machine-ல் root உரிமையை வழங்க வேண்டாம்.

SSH key-ஐ server-ல் வைக்காமல், agent-ஐ எப்படி git-ல் push செய்ய வைப்பது?

நீங்கள் connect செய்யும்போது ssh -A மூலம் உங்கள் SSH agent-ஐ forward செய்யவும். Private key உங்கள் laptop-லேயே இருக்கும், signature கோரிக்கைகள் மட்டும் connection வழியாகச் செல்லும். இதனால் ssh -T git@github.com மூலம் authentication நடக்கும், மேலும் git push எந்தவித private key-யும் server-ல் இல்லாமல் வேலை செய்யும். இதில் உள்ள சிக்கல் என்னவென்றால், நீங்கள் connected-ல் இருக்கும்போது அந்த server-ன் root பயனர் இந்த forwarded socket-ஐப் பயன்படுத்த முடியும். எனவே, மற்றவர்களுடன் பகிரும் எந்த machine-லும் repository-scoped deploy key-ஐப் பயன்படுத்தவும்.

Agent-க்கு எந்த அளவுள்ள VPS தேவை?

Agent-ன் வேலை பெரும்பாலும் கோப்புகளைத் திருத்துவது, build செய்வது மற்றும் test-களை இயக்குவதுதான். எனவே, model-ன் தேவைக்கு ஏற்ப அல்லாமல், build-ன் தேவைக்கு ஏற்ப machine-ன் அளவைத் தீர்மானிக்கவும். Hosted model, வழங்குநரின் (provider) hardware-ல் இயங்குவதால், அது network traffic-ஐ மட்டுமே அதிகரிக்கும், local load-ஐ ஏற்படுத்தாது. இருப்பினும், agent-ன் அடிப்படைத் தேவை உள்ளது: அக்டோபர் 20, 2026 நிலவரப்படி, Claude Code-ன் கணினித் தேவைகள் குறைந்தபட்சம் 4 GB RAM-ஐக் குறிப்பிடுகின்றன. Scripting வேலைகளுக்குக்கூட 4 GB-ல் தொடங்கி, repository-ல் containers build செய்யப்பட்டாலோ அல்லது பெரிய அளவில் compilation நடந்தாலோ 8 GB-க்கு உயர்த்தவும்.

Machine-ஐ எவ்வளவு அடிக்கடி அழித்து மீண்டும் உருவாக்க வேண்டும்?

Machine-ன் நிலை (state) விளக்க முடியாததாக மாறும்போது அதை மீண்டும் உருவாக்கவும். குறைந்தபட்சம், அந்த machine-ல் உள்ள ஏதேனும் ஒரு credential வெளிப்பட்டிருக்கலாம் என்று சந்தேகம் எழுந்தால், உடனடியாக மீண்டும் உருவாக்கவும். பணிகளுக்கு இடையே புதிய checkout செய்வது அன்றாட மாற்றங்களை (drift) நிர்வகிக்க உதவும். முதல் agent run-க்கு முன்பு எடுக்கப்பட்ட snapshot, நீங்கள் மீண்டும் பழைய நிலைக்குத் திரும்ப ஒரு சுத்தமான system image-ஐ வழங்கும். மீண்டும் உருவாக்குவது கடினமாகத் தோன்றினால், நீங்கள் 'தற்காலிகமானது' என்று கருதிய machine-ல் ஏதோ முக்கியமான ஒன்று இயங்குகிறது என்று அர்த்தம்.