tmuxతో రిమోట్ VPSలో Claude Code ఎలా నడపాలి

సమస్య CLIలో కాదు, laptop lidలో ఉంది

మీ laptopపై Claude Code సరిగ్గా నడుస్తుంది. కానీ laptopను మూసిన వెంటనే SSH session ముగుస్తుంది, shellకు SIGHUP సంకేతం అందుతుంది, దాంతో test run ప్రారంభించి మూడు నిమిషాలైన agent కూడా ఆగిపోతుంది. ఎప్పుడూ sleepలోకి వెళ్లని machineపై CLIని నడపండి. మీ SSH sessionకు child processes కాని ప్రక్రియలను నిర్వహించే terminal multiplexerలో దాన్ని ప్రారంభించండి. ఇదే మొత్తం పరిష్కారం. ఇక్కడ install కంటే tmux ముఖ్యమైన భాగం.

Agentsను నడుస్తూనే ఉంచే boxను నిర్వహించడం గురించి ఈ పేజీ వివరిస్తుంది. ఎప్పుడూ switched onగా ఉంచగల Linux server మీ వద్ద లేకపోతే, ఇందులోని సూచనలు ఏవీ వర్తించవు. ఇదే నిజాయితీగా చెప్పాల్సిన ఏకైక prerequisite.

tmux వాస్తవంగా చేసే పని

మీరు SSH ద్వారా కనెక్ట్ అయినప్పుడు, sshd ఒక shell ను fork చేసి దానికి pseudo-terminal ను అందిస్తుంది. ఆ shell నుంచి మీరు ప్రారంభించే ప్రతి ప్రక్రియ దాని child అవుతుంది. కనెక్షన్ తెగిపోతే kernel pty ను తొలగిస్తుంది. shell కు SIGHUP అందుతుంది. ఆ signal ను అది తన child ప్రక్రియలకు కూడా పంపుతుంది. Foreground లో దీర్ఘకాలం నడిచే ప్రక్రియలు ఆగిపోతాయి.

tmux లో ఈ ownership విధానం విరుద్ధంగా ఉంటుంది. మీరు టైప్ చేసే tmux command, unix socket ద్వారా terminal నుంచి వేరుగా నడుస్తున్న tmux server తో మాట్లాడే thin client మాత్రమే. Session లోని shells, sshd కు కాకుండా ఆ server కు child processes గా ఉంటాయి. SSH కనెక్షన్‌ను ముగించినప్పుడు client మాత్రమే ఆగిపోతుంది. server, session, అలాగే మధ్యలో పని చేస్తున్న agent కొనసాగుతాయి. మళ్లీ కనెక్ట్ అయి, tmux attach నడిపితే, అదే shell లోకి తిరిగి ప్రవేశిస్తారు. అదే scrollback కూడా అందుబాటులో ఉంటుంది. nohup hangup తర్వాత కూడా కొనసాగుతుంది. అయితే దానిలోకి తిరిగి ప్రవేశించే మార్గం ఉండదు. Background కు పంపిన TUI కు మళ్లీ attach కాలేరు. Claude Code interactive గా ఉంటుంది. అందువల్ల tmux లేదా screen సరైన సాధనం.

సర్వర్ పరిమాణం

CLI ఒక Node process. ఇది సాధారణంగా మొత్తం మెషీన్ వనరులను వినియోగించదు. మీ తరఫున agent అమలు చేసేవే వనరులను వినియోగిస్తాయి: build, పూర్తి test suite, tsc, language server, Dockerలో database. కాబట్టి CLI కోసం కాకుండా మొత్తం toolchain కోసం సర్వర్ పరిమాణాన్ని నిర్ణయించండి. దాన్ని ఎప్పుడూ ఉపయోగించకపోయినా swap ను జోడించండి. అలా చేస్తే కఠినమైన OOM kill కు బదులుగా build నెమ్మదిగా కొనసాగుతుంది:

sudo fallocate -l 4G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Disk ను కూడా monitor చేయండి. repos, node_modules మరియు Docker images వేగంగా పేరుకుపోతాయి. toolchain containers ను దాటి పూర్తి virtual machines వరకు చేరితే, ఉదాహరణకు KVM guest లేదా local Kubernetes node ఉపయోగిస్తే, సర్వర్‌ను ఖరారు చేసే ముందు plan లో CPU virtualisation extensions అందుబాటులో ఉన్నాయో లేదో నిర్ధారించండి. ఎందుకంటే VPSలో nested virtualization నడపడం provider enable చేయాల్సిన విషయం; guest లోపల నుంచి మీరు స్వయంగా enable చేయలేరు.

ముందుగా root కాని user

దానికి ప్రత్యేక home directory ఉన్న dedicated user ను సృష్టించి, మీ public key ను అక్కడ ఉంచండి:

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/.ssh
sudo cp ~/.ssh/authorized_keys /home/agent/.ssh/authorized_keys
sudo chown agent:agent /home/agent/.ssh/authorized_keys
sudo chmod 600 /home/agent/.ssh/authorized_keys

తదుపరి దశకు వెళ్లే ముందు రెండవ terminal నుంచి login చేసి పరీక్షించండి. Fallbackగా password authentication ఇంకా అందుబాటులో ఉండాలి. login సమయంలో Permission denied (publickey) వస్తే, సమస్య సాధారణంగా keyలో కాదు; ఆ .ssh directory యొక్క ownership లేదా modeలో ఉంటుంది.

ఉద్దేశపూర్వకంగా, agent ను sudo groupలో చేర్చలేదు. System package అవసరమైతే, దాన్ని మీరు install చేయాలి. ఈ ఒక్క నిర్ణయం వల్ల అనుకోకుండా అమలైన shell command hostను పాడుచేసే చాలా మార్గాలు తొలగిపోతాయి.

ఎల్లప్పుడూ నడుస్తూ ఉండే సర్వర్‌కు SSH భద్రతా పద్ధతులు

పబ్లిక్ ఇంటర్నెట్‌కు రోజంతా అనుసంధానమై ఉండే, agent మరియు మీ source code ను కలిగి ఉన్న యంత్రంలో password authentication కొనసాగించడం అవసరం లేని ప్రమాదం. దాన్ని ఆపివేయండి. Ubuntu 24.04 మరియు Debian 13లో /etc/ssh/sshd_configలో /etc/ssh/sshd_config.d/*.conf చేర్చబడి ఉంటుంది. అందువల్ల ప్రధాన config ను సవరించకుండా ప్రత్యేక file ను చేర్చండి:

# /etc/ssh/sshd_config.d/10-hardening.conf
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitRootLogin no

ప్రస్తుత session ను తెరిచి ఉంచి, రెండవ terminal నుంచి కొత్త session తో పరీక్షిస్తూ configuration ను validate చేసి reload చేయండి:

sudo sshd -t && sudo systemctl restart ssh

Ubuntu 24.04లో ఒక ప్రత్యేక విషయం ఉంది: sshd socket-activated గా ఉంటుంది. Authentication settings systemctl restart sshపై అమలవుతాయి. అయితే listening Portలో మార్పు చేసినప్పుడు systemctl daemon-reload మరియు ssh.socket restart కూడా అవసరం.

తరువాత firewall. దాన్ని enable చేయడానికి ముందే SSHను allow చేయండి. లేకపోతే మీరు మీరే బయటపడిపోతారు:

sudo ufw allow OpenSSH
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

fail2banను ఇన్‌స్టాల్ చేసే ముందు, దాని ప్రయోజనం ఏమిటో స్పష్టంగా అర్థం చేసుకోండి. Password authentication ఆపివేసిన తర్వాత brute-force ప్రయత్నాలు విజయవంతం కాలేవు. అయితే ఇది విఫలమైన ప్రయత్నాలను మీ journalలోకి రాకుండా నిరోధిస్తుంది.

# /etc/fail2ban/jail.local
[sshd]
enabled = true
backend = systemd
maxretry = 5
bantime = 1h

చివరగా sudo apt install unattended-upgrades మరియు sudo dpkg-reconfigure -plow unattended-upgradesతో automatic patchingను ప్రారంభించండి. tmuxతో ఉన్న పరస్పర ప్రభావాన్ని గమనించండి: Unattended-Upgrade::Automatic-Rebootను enable చేస్తే kernel update తర్వాత box reboot అవుతుంది. దాంతో అన్ని sessionలు కూడా ముగుస్తాయి. దీన్ని offలో ఉంచి, ఏ పని కూడా మధ్యలో నడవని సమయంలో మీ స్వంత schedule ప్రకారం reboot చేయండి. ఇదే జాగ్రత్త release upgradeకూ వర్తిస్తుంది: Ubuntu 24.04 నుంచి 26.04కు boxను upgrade చేయడం sshd మరియు kernelను restart చేస్తుంది. అందువల్ల మీరు ముఖ్యమైన పని నడుపుతున్న tmux session ఏదీ లేని maintenance windowలో దీన్ని చేయాలి.

Ubuntuలో Node.js మరియు Claude Code ఇన్‌స్టాల్ చేయడం

Claude Code ఒక Node CLI. అందువల్ల ప్రస్తుత Node అవసరం. Distro package తరచుగా పాతదిగా ఉంటుంది. Ubuntu మరియు Debianలో సాధారణంగా NodeSourceని ఉపయోగిస్తారు. ఇది signed repoను అందిస్తుంది. apt-key అవసరం లేదు. ఆ tool తొలగించబడింది:

curl -fsSL https://deb.nodesource.com/setup_24.x | sudo -E bash -
sudo apt install -y nodejs
node --version

ఇక్కడ చాలామంది చేసే తప్పును నివారించాలి: CLIని మీ agent userగా ఇన్‌స్టాల్ చేయాలి. ఎప్పుడూ sudo npm -gతో ఇన్‌స్టాల్ చేయకండి. root-owned global prefix వల్ల తరువాత permission errors వస్తాయి. అలాగే npm cacheలో root-owned files మిగులుతాయి. ముందుగా npm prefixను user homeకు సెట్ చేయండి:

mkdir -p ~/.npm-global
npm config set prefix ~/.npm-global
echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc
npm install -g @anthropic-ai/claude-code
claude --version

ఈ exportను ~/.bashrcలో ఉంచాలి. ~/.profileలో కాదు. ఫైల్ పైభాగంలో ఉన్న "If not running interactively, don't do anything" guardకు పైన ఉంచాలి. tmux non-login shellsను ప్రారంభించవచ్చు. అవి ~/.bashrcను చదివి ~/.profileను skip చేస్తాయి. ~/.profile login shells కోసం మాత్రమే అమలవుతుంది. nvm వంటి version manager ద్వారా per-user Nodeను ఇన్‌స్టాల్ చేసినా ఇదే ఫలితం వస్తుంది. రెండు మార్గాల్లోనూ లక్ష్యం ఒకటే: npm install -gకు ఎప్పుడూ sudo అవసరం ఉండకూడదు. npmను అలాగే ఉపయోగించవచ్చు. లేదా Anthropic యొక్క native install scriptను ఉపయోగించండి. ప్రస్తుతం documentationలో అదే defaultగా ఉంది. Paste చేసే ముందు Anthropic install docsను పరిశీలించండి. Install methods మారవచ్చు.

Repoలో claudeను అమలు చేసి దాన్ని ప్రారంభించండి. మొదటి runలో authentication దశలు కనిపిస్తాయి. Headless boxలో browser ఉండదు. అందువల్ల మీ స్వంత machineలో తెరవాల్సిన URLను, terminalకు తిరిగి తీసుకురావాల్సిన codeను ఈ flow అందిస్తుంది. Environmentలో API key ఉంచడం మరో మార్గం. ఏ మార్గాన్ని ఎంచుకున్నా ఆ credential ఇప్పుడు serverలో ఉంటుంది. దీనితో చాలామంది విస్మరించే తదుపరి అంశానికి వస్తాం.

వ్యాప్తి ప్రభావంపై చర్చ

Shell యాక్సెస్ ఉన్న agent ఒక shell వంటిదే. అది తాను నడుస్తున్న user చదవగలిగే ఏదైనా చదవగలదు, అలాగే ఆ user push చేయగలిగే ఎక్కడికైనా push చేయగలదు. ఇది ఆ tool పై విమర్శ కాదు. అదే దాని నిర్వచనం. అందుకే agent నడిచే account, ఏ ఒక్క setting కంటే ఎక్కువ ముఖ్యమైనది.

• ప్రత్యేక unprivileged user. sudo group ఉండకూడదు. మీ స్వంత account తో home directory share చేయకూడదు.
• ఆ box లో production credentials ఉండకూడదు. prod keys కలిగిన ~/.aws/credentials ఉండకూడదు. production నుంచి కాపీ చేసిన .env ఉండకూడదు. ముఖ్యమైన ఏ వనరుకైనా write access ఉన్న database password ఉండకూడదు. Agent కు staging లేదా read-only credential ఇవ్వండి.
• పరిధి నిర్దేశించిన tokens. ఒక repository కి మాత్రమే పరిమితం చేసిన fine-grained GitHub token ఉపయోగించండి. Read access సరిపోతే deploy key ఉపయోగించండి.

Claude Code దాని permission prompts ను పూర్తిగా దాటవేసే flag ను అందిస్తుంది. Laptop లేదా తాత్కాలిక project విషయంలో దాన్ని ఉపయోగించాలా వద్దా అనేది మీ నిర్ణయం. కానీ tokens ఉన్న server లో అది తప్పుగా అర్థం చేసుకున్న instruction మరియు git push --force మధ్య నిలిచిన చివరి రక్షణను తొలగిస్తుంది. మీరు దాటవేయబోయే prompts అన్నీ ఒకే రకమైనవి కావు. auto mode కొత్త default గా మారుతున్నందున, మీరు పర్యవేక్షించని server ఏ permission mode కు పరిమితం కావాలో తెలుసుకోవడం ఉపయోగకరం. ఆ flag నిజంగా ఏమి మారుస్తుంది, అలాగే దానితో నడిచే agent ను built-in sandbox నుంచి disposable VPS వరకు ఎలా నియంత్రించాలి అనే విషయం server లో Claude Code ను సురక్షితంగా నడపడం లో వివరించబడింది.

Deploy key మరియు SSH agent forwarding మధ్య తేడా

git మీ laptop లోని key ను ఉపయోగించేందుకు ssh -A చేయడం ఆకర్షణీయంగా అనిపించవచ్చు. కానీ ఇది ఏమి అనుమతిస్తుందో తెలుసుకోండి: agent forwarding, ఆ box లో ఆ user గా నడుస్తున్న processes కు మీ local SSH agent యొక్క socket ను అందుబాటులో ఉంచుతుంది. Agent సహా agent గా నడుస్తున్న ఏదైనా process, మీరు connected గా ఉన్నంతకాలం, అది చేరుకోగల ఏ host కోసమైనా మీ key తో sign చేయమని అడగగలదు. ఇది “ఈ ఒక్క repo ను git pull చేయనివ్వండి” అనే దానికంటే చాలా ఎక్కువ.

దానికి బదులుగా server పై key ను generate చేయండి. దాన్ని ప్రతి repository కి deploy key గా register చేయండి. Agent push చేయాల్సి ఉంటే మాత్రమే write access ఇవ్వండి. తరువాత box నుంచి చేసిన commits ను సులభంగా గుర్తించగలిగేలా git identity ను set చేయండి:

ssh-keygen -t ed25519 -C "agent deploy key" -f ~/.ssh/id_ed25519_repo
cat ~/.ssh/id_ed25519_repo.pub   # paste into the repo's Deploy Keys
git config --global user.name "Agent (build box)"
git config --global user.email "agent@example.com"

tmux వర్క్‌ఫ్లో

దాన్ని ఇన్‌స్టాల్ చేయండి (sudo apt install tmux), తరువాత కనిష్ఠంగా ~/.tmux.conf ను ఉపయోగించండి:

set -g mouse on
set -g history-limit 50000
set -g default-terminal "tmux-256color"

రోజువారీ వినియోగానికి నాలుగు ఆదేశాలు సరిపోతాయి:

tmux new -A -s claude     # attach to session "claude", creating it if absent
# ...run `claude` inside it, work normally...
# Ctrl-b then d           -> detach; everything keeps running
tmux ls                   # list sessions
tmux attach -t claude     # reattach, from this machine or any other
tmux kill-session -t claude

tmux new -A -s claude ను తప్పక గుర్తుంచుకోండి. Session ఇప్పటికే ఉంటే ఇది దానికి attach అవుతుంది. Session లేకపోతే దాన్ని సృష్టిస్తుంది. అందువల్ల రోజు ప్రారంభించడానికి మరియు connection తెగిన తర్వాత మళ్లీ కొనసాగించడానికి ఒకే ఆదేశం సరిపోతుంది. దీనికి alias సెట్ చేయండి. Session లో Ctrl-b c కొత్త window ను తెరుస్తుంది. Ctrl-b n మరియు Ctrl-b p windows మధ్య మారుస్తాయి. Ctrl-b [ copy mode లోకి ప్రవేశిస్తుంది, దాంతో వెనక్కి scroll చేయవచ్చు (దాని నుంచి బయటకు రావడానికి q నొక్కండి).

మీరు ఎప్పుడూ kill చేయని sessions గురించి ఒక విషయం తెలుసుకోవాలి: agent ప్రతి turn లో మొత్తం conversation ను మళ్లీ పంపుతుంది. కాబట్టి ఒక session ను వారం రోజుల పాటు నడుస్తూ వదిలే ముందు దీర్ఘకాలం నడిచే Claude Code session తన tokens ను దేనికి ఖర్చు చేస్తుందో చదవండి.

విఫలమయ్యే పరిస్థితులు

"నా session కనిపించడంలేదు." tmux ls, no server running on /tmp/tmux-1000/default ను ముద్రిస్తుంది. దాదాపు ఎల్లప్పుడూ దీని అర్థం process tmux లో ఎప్పుడూ నడవలేదు, మీరు SSH ద్వారా login అయి, claude ను నేరుగా అమలు చేశారు, disconnect కావడంతో అది ఆగిపోయింది. పునరుద్ధరించడానికి ఏమీ ఉండదు. దీనిని నివారించే అలవాటు: ప్రతి login తర్వాత అమలు చేసే మొదటి command tmux new -A -s <project> అయి ఉండాలి.

Pane చిన్న పెట్టెలా మారుతుంది. tmux, session కు attach అయి ఉన్న client‌లలో అతి చిన్న పరిమాణాన్ని ఉపయోగిస్తుంది. అందువల్ల మరో machine నుంచి ఇంకా attach అయి ఉన్న పాత client display‌ను కుదిస్తుంది. మీరు attach అవుతున్నప్పుడు ఇతర client‌లను బలవంతంగా తొలగించండి: tmux attach -d -t claude.

Build Killed ను ముద్రిస్తుంది. ఒక్క పదమే కనిపిస్తుంది; stack trace ఉండదు. sudo dmesg -T | grep -i -E 'out of memory|killed process' తో నిర్ధారించండి. Kernel OOM killer ఎక్కువ memory ఉపయోగిస్తున్న process‌ను ఎంచుకుంది. Node నుంచి బదులుగా FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory కనిపించవచ్చు. పరిష్కారాలను ఈ క్రమంలో ప్రయత్నించండి: పైన పేర్కొన్న విధంగా swap జోడించండి, test మరియు compiler parallelism కు పరిమితి విధించండి, NODE_OPTIONS=--max-old-space-size=... తో Node heap పరిమాణాన్ని పెంచండి, లేదా VPS పరిమాణాన్ని పెంచండి. OOM killer build‌కు బదులుగా tmux server ను కూడా ఎంచుకోవచ్చు. అప్పుడు మీ session కూడా ముగుస్తుంది. systemd-oomd నడుస్తుంటే, అదే ప్రభావంతో మొత్తం user slice‌ను అది ముగించవచ్చు.

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'. root యాజమాన్యంలోని prefix లో global install చేయడానికి ప్రయత్నించారు. పైన పేర్కొన్న ~/.npm-global prefix‌ను ఉపయోగించండి. మీరు ఇప్పటికే ఎప్పుడైనా sudo npm అమలు చేసి ఉంటే Your cache folder contains root-owned files కూడా కనిపించవచ్చు. దాన్ని sudo chown -R $(id -u):$(id -g) ~/.npm తో సరిచేయండి.

claude: command not found, కానీ కొన్నిసార్లు మాత్రమే. మీ PATH export, "If not running interactively, don't do anything" guard కింద ఉన్న ~/.bashrc లో ఉంది. అందువల్ల non-interactive shells దాన్ని దాటవేస్తాయి. ఆ export‌ను guard పైనకు తరలించండి. దాన్ని ~/.bashrc లో ఉంచండి, ~/.profile లో కాదు. tmux non-login shells‌ను ప్రారంభించవచ్చు. అవి ~/.bashrc ను చదువుతాయి, కానీ ~/.profile ను ఎప్పుడూ చదవవు.

Attach చేసిన తర్వాత రంగులు గందరగోళంగా కనిపిస్తాయి. ఇది TERM mismatch వల్ల జరుగుతుంది. పైన ఉన్న default-terminal line దీనికి పరిష్కారం.

Reboot తర్వాత sessions కనిపించవు. ఇది bug కాదు. tmux server ఒక process, reboot దాన్ని ముగిస్తుంది. uptime ను పరిశీలించండి.

ఇది పెరిగే కొద్దీ ఏమి సమస్యలు వస్తాయి

మరిన్ని ప్రాజెక్టులు. ప్రతి repository కి దాని పేరుతో ఒక tmux session సృష్టించండి; అప్పుడు tmux ls మీ dashboard గా పనిచేస్తుంది. పేర్లు పెట్టే క్రమశిక్షణను పాటించకపోతే 0, 1, 2 వంటి sessions ఏర్పడతాయి. ఒకేసారి అనేక sessions నడుస్తున్నప్పుడు అవి తప్పనిసరిగా వేరువేరుగా పనిచేయాల్సిన అవసరం లేదు. ఎందుకంటే అదే సిస్టమ్‌లో ఒక session మరొక session కు message పంపగలదు. దీర్ఘమైన refactor నిర్వహిస్తున్న agent, tests అమలు చేయడానికి మరొక agent ను ప్రారంభించాల్సినప్పుడు ఇది ఉపయోగకరంగా ఉంటుంది. Ports కూడా ఇదే విధంగా పెరుగుతాయి. ఆరు repositories అన్నీ :3000 కోరుతున్నప్పుడు ports ను చేతితో కేటాయించడం ఆపి, Docker Compose కింద అనేక apps కు hostname ఆధారంగా route చేయడానికి Traefik reverse proxy ను ఉపయోగించడం సరైన పద్ధతి.

మరిన్ని వ్యక్తులు. tmux sockets ప్రతి user కు వేరు. అందువల్ల ఒకే సిస్టమ్‌లో ఉన్న ఇద్దరు developers కు తమ తమ tmux server ఉంటుంది. వారు ఒకరి sessions ను మరొకరు చూడలేరు. Shared socket ద్వారా ఒకే session ను పంచుకుంటే, అందరూ అదే Unix user గా నడుస్తున్న ఒకే shell లో commands టైప్ చేస్తారు. దీనివల్ల audit మరియు permissions పరంగా వచ్చే ప్రభావాలు కూడా ఉంటాయి. వేర్వేరు users ను ఉపయోగించడం సాధారణమైనదైనా సరైన పరిష్కారం.

పర్యవేక్షణ లేకుండా నడిచే పనులు. మీరు attach అయ్యే interactive sessions కోసం tmux ఉద్దేశించబడింది. ఎవరూ పర్యవేక్షించకుండా schedule ప్రకారం నడిచే jobs ను systemd unit మరియు timer లో అమలు చేయాలి. అక్కడ logging, restart policy, boot తర్వాత కూడా కొనసాగించే సామర్థ్యం స్వయంచాలకంగా లభిస్తాయి. cron తరహా job ను అమలు చేయడానికి tmux ను ఉపయోగించాలని అనిపిస్తే, ఆ job ను service గా నిర్వహించాల్సిన అవసరం ఉందని అర్థం.

చివరి సూచన: agent ప్రారంభించే dev servers ను 127.0.0.1 కు bind చేయండి, 0.0.0.0 కు కాదు. Ports ను ufw లో తెరవడం బదులుగా SSH tunnel (ssh -L 3000:127.0.0.1:3000 agent@your-server) ద్వారా వాటిని చేరుకోండి. మీరు అరడజను ports ను forward చేస్తున్నప్పుడు, లేదా phone మరియు laptop రెండూ ఒకే preview ను ఉపయోగించాలనుకున్నప్పుడు, వాటి ముందు VPS పై self-hosted WireGuard VPN ను అమర్చండి. అప్పుడు dev servers private interface కు bind అవుతాయి. ufw public interface నుంచి వచ్చే ప్రతిదాన్ని తిరస్కరిస్తూనే ఉంటుంది. Firewall లోకి holes తెరవడం ఆపకపోతే firewall రక్షణ ఇవ్వదు.

Claude Code మాత్రమే ఉన్న ఎంపిక కాదు: VPS పై coding AI agent ను నడపడం లో Aider మరియు Goose కూడా పరిగణనలోకి వస్తాయి.

FAQ

Claude Code మీ SSH connection తెగిపోయిన తర్వాత కూడా నడుస్తుందా?

మీరు దాన్ని tmux లో ప్రారంభించి ఉంటే మాత్రమే. SSH shell నుంచి నేరుగా ప్రారంభించిన process ఆ shell కు child process గా ఉంటుంది. కనెక్షన్ తెగినప్పుడు pty తో పాటు అది కూడా ఆగిపోతుంది. tmux లో shell, detached tmux server కు చెందినది. అందువల్ల agent పని మధ్యలో ఉన్నప్పటికీ కొనసాగుతుంది. తిరిగి కనెక్ట్ అయినప్పుడు tmux attach మిమ్మల్ని అదే scrollback కు తీసుకువెళుతుంది. ప్రతి login తర్వాత tmux new -A -s <project> ను మొదటి command గా అమలు చేయండి. అప్పుడు ఈ సమస్య ఉండదు.

నేను CLI ను sudo npm install -g తో install చేయాలా?

లేదు. root యాజమాన్యంలోని global prefix, తరువాతి installs సమయంలో EACCES errors కు దారితీస్తుంది. npm cache లో root యాజమాన్యంలోని files కూడా ఏర్పడతాయి. npm యొక్క prefix ను ~/.npm-global కు set చేయండి. లేదా nvm వంటి version manager ను ఉపయోగించండి. unprivileged agent user గా install చేయండి. తరువాత ~/.bashrc నుంచి PATH పైకి ~/.npm-global/bin ను export చేయండి. దీన్ని interactive guard పైన ఉంచాలి. మీరు ఇప్పటికే sudo npm ను ఒకసారి అమలు చేసి ఉంటే, sudo chown -R $(id -u):$(id -g) ~/.npm తో cache ను సరిచేయండి.

agent నడుస్తున్న box లో ssh -A agent forwarding సురక్షితమేనా?

అది job కు అవసరమైన దానికంటే చాలా ఎక్కువ అనుమతులు ఇస్తుంది. Forwarding వల్ల మీ local SSH agent యొక్క socket, ఆ user గా నడుస్తున్న ప్రతి process కు అందుబాటులోకి వస్తుంది. అందువల్ల మీరు session కు అనుసంధానంగా ఉన్నంతకాలం, ఆ box లోని ఏదైనా process తనకు చేరుకోగల host కోసం మీ key తో sign చేయమని అడగవచ్చు. Server పై ed25519 key ను generate చేసి, దాన్ని ప్రతి repository కు ప్రత్యేక deploy key గా register చేయండి. Agent కు push చేయాల్సిన అవసరం ఉన్నప్పుడు మాత్రమే write access ఇవ్వండి.

నా build కేవలం Killed ను ఎందుకు print చేస్తోంది?

Stack trace లేకుండా ఒకే పదం కనిపిస్తే కారణం kernel OOM killer కావచ్చు. sudo dmesg -T | grep -i -E 'out of memory|killed process' తో నిర్ధారించండి. Node నుంచి బదులుగా JavaScript heap out of memory కనిపించవచ్చు. పరిష్కారాలను క్రమంగా అమలు చేయండి: swapfile ను జోడించండి, test మరియు compiler parallelism కు పరిమితి విధించండి, NODE_OPTIONS=--max-old-space-size=... ను పెంచండి, తరువాత VPS పరిమాణాన్ని పెంచండి. OOM killer build కు బదులుగా tmux server ను ఎంచుకునే అవకాశం ఉంది. అప్పుడు మీ మొత్తం session కూడా ఆగిపోతుంది.

tmux లేదా systemd service?

మీరు attach అయి పరిశీలిస్తూ commands టైప్ చేసే interactive sessions కు tmux అనుకూలంగా ఉంటుంది. Agent session కూడా ఇదే విధమైనది. ఎవరూ పర్యవేక్షించని, schedule ప్రకారం నడిచే పని systemd unit మరియు timer లో ఉండాలి. అక్కడ logging, restart policy మరియు boot తర్వాత కూడా కొనసాగడం వంటి సౌకర్యాలు సహజంగానే లభిస్తాయి. cron వంటి job నడపడానికి tmux ఉపయోగించాలనిపిస్తే, ఆ job కు service అవసరం.