Claude Code-ஐ remote VPS-ல் tmux மூலம் இயக்குவது எப்படி?

சிக்கல் மடிக்கணினியின் மூடியில் உள்ளது, CLI-ல் அல்ல

நீங்கள் மடிக்கணினியை மூடும் வரை Claude Code சரியாக இயங்கும்: அப்போது SSH session முடிவுக்கு வரும், shell-க்கு SIGHUP சிக்னல் அனுப்பப்படும், மேலும் சோதனை ஓட்டத்தின் மூன்று நிமிடங்களில் agent-ம் அதனுடன் நின்றுவிடும். உறக்க நிலைக்குச் செல்லாத ஒரு கணினியில் CLI-ஐ இயக்கவும்; உங்கள் SSH session-ன் child process-களாக இல்லாத ஒரு terminal multiplexer-க்குள் இதைச் செய்யவும். இதுவே முழுமையான தந்திரம்; நிறுவல் (install) முக்கியமல்ல, tmux-தான் இங்கு அடிப்படைத் தேவையாகும்.

இது நீங்கள் agent-களை இயங்க விட்டுச் செல்லும் ஒரு கணினியை நிர்வகிப்பது குறித்த பக்கம். எப்போதும் இயங்கக்கூடிய Linux server உங்களிடம் இல்லையென்றால், இதில் எதுவும் உங்களுக்குப் பொருந்தாது. இதுவே இதற்கான ஒரே உண்மையான முன்நிபந்தனை.

tmux உண்மையில் என்ன செய்கிறது

நீங்கள் SSH மூலம் நுழையும்போது, sshd ஒரு shell-ஐ உருவாக்கி அதற்கு ஒரு pseudo-terminal-ஐ வழங்குகிறது; அந்த shell-லிருந்து நீங்கள் தொடங்கும் அனைத்தும் அதன் child process-கள் ஆகும். இணைப்பைத் துண்டித்தால், kernel அந்த pty-ஐ நீக்கிவிடும், shell-க்கு SIGHUP சிக்னல் கிடைக்கும், அது தனது child process-களையும் முடித்துவிடும். நீண்ட நேரம் இயங்கும் foreground process-கள் இதனால் நின்றுவிடும்.

tmux இந்த உரிமையின் தன்மையை மாற்றுகிறது. நீங்கள் தட்டச்சு செய்யும் tmux கட்டளை, உங்கள் terminal-லிருந்து பிரிக்கப்பட்டு இயங்கும் ஒரு tmux server-உடன் unix socket வழியாகத் தொடர்பு கொள்ளும் ஒரு மெல்லிய client ஆகும். ஒரு session-க்குள் இருக்கும் shell-கள் sshd-ன் child process-கள் அல்ல, அவை அந்த server-ன் child process-கள். SSH இணைப்பைத் துண்டித்தால் client மறைந்துவிடும், ஆனால் server, session மற்றும் பணியில் இருக்கும் agent தொடர்ந்து இயங்கும். மீண்டும் இணைப்பை ஏற்படுத்தி, tmux attach கட்டளையைப் பயன்படுத்தினால், அதே shell மற்றும் scrollback தரவுகளுடன் நீங்கள் மீண்டும் அதே இடத்திற்கு வந்துவிடலாம். nohup-ம் hangup-ஐத் தாங்கி இயங்கும், ஆனால் மீண்டும் உள்ளே நுழைய வழி தராது; background-க்குச் சென்ற TUI-உடன் உங்களால் மீண்டும் இணைய முடியாது. Claude Code ஒரு interactive கருவி; அதற்கு tmux (அல்லது screen) சரியான கருவியாகும்.

server-ன் அளவைத் தீர்மானித்தல்

CLI என்பது ஒரு தனிப்பட்ட native binary மட்டுமே; இது server-ன் நினைவகத்தை முழுமையாக நிரப்பாது. உங்கள் சார்பாக இயங்கும் agent-களே server-ன் வளங்களை அதிகம் பயன்படுத்தும்: ஒரு build, முழுமையான test suite, tsc, ஒரு language server, அல்லது Docker-ல் இயங்கும் database போன்றவை. CLI-க்காக அல்லாமல், உங்கள் toolchain-ன் தேவைக்கேற்ப server-ன் அளவைத் தேர்வு செய்யவும். Swap memory-ஐச் சேர்க்கவும்; நீங்கள் அதைப் பயன்படுத்தப் போவதில்லை என்றாலும், இது திடீரென ஏற்படும் 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 பயன்பாட்டையும் கவனிக்கவும்: repos, node_modules மற்றும் Docker images ஆகியவை மிக வேகமாக இடத்தைப் பிடிக்கும். உங்கள் toolchain, containers-ஐத் தாண்டி முழுமையான virtual machines, KVM guest, அல்லது local Kubernetes node என விரிவடைந்தால், CPU virtualization extensions வசதி உள்ளதா என்பதை உறுதிப்படுத்தவும். ஏனெனில், VPS-ல் nested virtualization-ஐ இயக்குவது என்பது, guest-க்குள் நீங்கள் மாற்றக்கூடிய ஒன்றல்ல, மாறாக service provider-ஆல் உங்களுக்கு வழங்கப்பட வேண்டிய ஒரு வசதியாகும்.

முதலில் ஒரு non-root user-ஐ உருவாக்குதல்

அதற்கென பிரத்யேக home directory கொண்ட ஒரு 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

Password authentication இன்னும் செயல்பாட்டில் இருக்கும்போதே, மற்றொரு terminal-லிருந்து login செய்ய முடிகிறதா என்று சோதிக்கவும். ஒருவேளை Permission denied (publickey) என்று பிழை வந்தால், அது பெரும்பாலும் .ssh directory-ன் ownership அல்லது mode அமைப்புகளில் உள்ள குறைபாடே தவிர, key-ல் உள்ள பிரச்சினை அல்ல.

திட்டமிட்டே, agent பயனர் sudo குழுவில் சேர்க்கப்படவில்லை. ஏதேனும் system package தேவைப்பட்டால், அதை நீங்கள் நிறுவிக்கொள்ளலாம். இந்த ஒரு முடிவு, கவனக்குறைவாக இயக்கப்படும் shell command-களால் host பாதிக்கப்படுவதைத் தவிர்க்க உதவுகிறது.

தொடர்ந்து இயங்கும் server-க்கான SSH பாதுகாப்பு நடைமுறைகள்

பொது இணையத்தில் (public internet) எப்போதும் இயங்கிக்கொண்டிருக்கும், source code மற்றும் agent-ஐக் கொண்டிருக்கும் ஒரு machine-ல் password authentication-ஐப் பயன்படுத்துவது தேவையற்ற ஆபத்து. அதை முடக்கவும். Ubuntu 24.04 மற்றும் Debian 13-ல், /etc/ssh/sshd_config ஆனது /etc/ssh/sshd_config.d/*.conf-ஐ உள்ளடக்கியுள்ளது. எனவே, பிரதான configuration கோப்பைத் திருத்துவதற்குப் பதிலாக, ஒரு புதிய கோப்பை உருவாக்கவும்:

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

குறிப்பிட்ட காரணம் இல்லையெனில், அந்த file-ல் key exchange-ஐ சேர்க்க வேண்டாம்: பழைய hardening guide-ல் இருந்து copy செய்யப்பட்ட KexAlgorithms line, பெரும்பாலும் classical algorithms-ஐ மட்டும் கட்டுப்படுத்தும். இதனால் recent ssh client, connection post-quantum key exchange-ஐ பயன்படுத்தவில்லை என்ற எச்சரிக்கையை காட்டக்கூடும்.

தற்போதைய session-ஐ மூடாமல், மற்றொரு terminal-லிருந்து புதிய இணைப்பைச் சோதித்து, மாற்றங்களை உறுதிப்படுத்தி reload செய்யவும்:

sudo sshd -t && sudo systemctl restart ssh

Ubuntu 24.04-ல் ஒரு நுணுக்கம்: sshd ஆனது socket-activated முறையில் இயங்குகிறது. Auth அமைப்புகள் systemctl restart ssh-ல் பொருந்தும், ஆனால் listening Port-ல் செய்யப்படும் மாற்றங்களுக்கு systemctl daemon-reload மற்றும் ssh.socket-ஐ restart செய்வது அவசியம்.

அடுத்து firewall. SSH-ஐ enable செய்வதற்கு முன்பே அதை அனுமதிக்கும் விதியைச் சேர்க்கவும், இல்லையெனில் நீங்கள் server-லிருந்து வெளியேற்றப்படுவீர்கள்:

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 மூலம் தானியங்கி patch-களைச் செய்யவும். tmux-உடனான அதன் தொடர்பைக் கவனிக்கவும்: Unattended-Upgrade::Automatic-Reboot-ஐ ஆன் செய்திருந்தால், kernel update நடக்கும்போது server தானாகவே reboot ஆகும், இது உங்கள் அனைத்து session-களையும் முடிவுக்குக் கொண்டுவரும். இதை off-ல் வைத்துவிட்டு, எந்த வேலையும் நடைபெறாத நேரத்தில் நீங்களாகவே reboot செய்யவும். இதே எச்சரிக்கை release upgrade-க்கும் பொருந்தும்: Ubuntu 24.04-லிருந்து 26.04-க்கு மாறுவது sshd மற்றும் kernel-ஐ restart செய்யும். எனவே, tmux session-ல் முக்கியமான வேலைகள் இல்லாத நேரத்தில் இதைச் செய்யவும்.

Ubuntu-வில் Node.js மற்றும் Claude Code நிறுவுதல்

npm வழிமுறைக்கு Node.js 22 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை. (இந்த package இப்போது Node-ல் இயங்காத ஒரு native binary-ஐப் பயன்படுத்துகிறது, ஆனால் npm இன்னும் engine version-ஐச் சரிபார்க்கிறது, மேலும் agent-ன் சொந்த toolchain-க்கு பொதுவாக தற்போதைய Node தேவைப்படும்.) Distro package பெரும்பாலும் பின்தங்கியே இருக்கும்; Ubuntu மற்றும் Debian-ல் NodeSource பொதுவான வழியாகும், இது கையொப்பமிடப்பட்ட repo-வை வழங்குகிறது (Ubuntu 24.04-ல் deprecated ஆகி, Debian 13-ல் நீக்கப்பட்ட apt-key இதில் இல்லை):

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

இப்போது மக்கள் தவறு செய்யும் பகுதி: CLI-ஐ உங்கள் agent பயனராக நிறுவுங்கள், ஒருபோதும் sudo npm -g-ஐப் பயன்படுத்த வேண்டாம். Root-க்குச் சொந்தமான global prefix பிற்காலத்தில் permission பிழைகளை உருவாக்கும் மற்றும் npm cache-ல் root-க்குச் சொந்தமான கோப்புகளை விட்டுவிடும். முதலில் npm-ன் prefix-ஐ பயனரின் home directory-க்கு மாற்றவும்:

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-ல் சேர்க்கப்பட வேண்டும், மேலும் இது கோப்பின் தொடக்கத்தில் உள்ள "If not running interactively, don't do anything" என்ற guard-க்கு மேலே இருக்க வேண்டும். ஒரு default tmux pane ஒரு login shell-ஐ இயக்குகிறது: tmux default-command-ஐ காலியாக விடுகிறது, இது default-shell-ஐ ஒரு login shell-ஆகத் தொடங்கச் சொல்கிறது, மேலும் ஒரு login bash ~/.profile-ஐ வாசிக்கும், இது Ubuntu-வில் ~/.bashrc-ஐ source செய்கிறது. Non-login shells, உதாரணமாக நீங்கள் default-command-ஐ நீங்களே அமைத்தால், ~/.bashrc-ஐ நேரடியாக வாசிக்கும். எனவே ~/.bashrc இரண்டு நிலைகளையும் உள்ளடக்கும், அதே சமயம் ~/.profile மட்டும் இருந்தால் இரண்டாவது நிலையைத் தவறவிடும். ஒரு சிக்கல்: ~/.bash_profile அல்லது ~/.bash_login இருந்தால் bash ~/.profile-ஐத் தவிர்க்கும், எனவே நீங்கள் ஒன்றை உருவாக்கியிருந்தால், அதையும் ~/.bashrc-ஐ source செய்ய வைக்கவும். nvm போன்ற version manager மூலம் ஒரு பயனருக்கான Node-ஐ அமைப்பதும் இதே முடிவைத் தரும்; எப்படியிருந்தாலும், npm install -g-க்கு ஒருபோதும் sudo தேவைப்படக்கூடாது என்பதே இலக்கு. npm நன்றாக வேலை செய்கிறது, ஆனால் Anthropic-ன் ஆவணங்கள் native install script-ஐ பரிந்துரைக்கப்பட்ட வழியாகக் குறிப்பிடுகின்றன, மேலும் கையொப்பமிடப்பட்ட apt, dnf மற்றும் apk repositories மற்றொரு விருப்பமாகும். நீங்கள் copy-paste செய்வதற்கு முன் Anthropic-ன் நிறுவல் ஆவணங்களைச் சரிபார்க்கவும், நிறுவல் முறைகள் மாறக்கூடும்.

அதைத் தொடங்க ஒரு repo-க்குள் claude-ஐ இயக்கவும். முதல் முறை இயக்கும்போது அது authentication செயல்முறைக்கு உங்களை அழைத்துச் செல்லும்; headless box-ல் browser இருக்காது, எனவே இந்த flow உங்களுக்கு ஒரு URL-ஐத் தரும், அதை உங்கள் கணினியில் திறந்து, ஒரு குறியீட்டை (code) terminal-க்குக் கொண்டு வர வேண்டும். (Environment-ல் உள்ள API key மற்றொரு வழியாகும்.) எப்படியிருந்தாலும், அந்த credential இப்போது server-ல் இருக்கும், இதுவே மக்கள் தவிர்க்கும் பகுதிக்கு நம்மை அழைத்துச் செல்கிறது.

தாக்கத்தின் எல்லை (Blast radius) குறித்த உரையாடல்

Shell access கொண்ட ஒரு agent என்பது ஒரு shell-க்கு சமம். அது எந்த user-ஆக இயங்குகிறதோ, அந்த user-ஆல் எதை வாசிக்க முடியுமோ அதை அதாலும் வாசிக்க முடியும்; எங்கு மாற்றங்களைச் செய்ய முடியுமோ அங்கெல்லாம் அதாலும் செய்ய முடியும். இது அந்த கருவியின் குறைபாடு அல்ல, அதுவே அதன் வரையறை. இதனால்தான், தனிப்பட்ட அமைப்புகளை விட, அது எந்த account-ன் கீழ் இயங்குகிறது என்பது மிக முக்கியமானது.

• பிரத்யேகமான, அதிகாரம் குறைந்த user. sudo group இருக்கக்கூடாது, உங்கள் சொந்த account-உடன் பகிரப்பட்ட home directory இருக்கக்கூடாது.
• Production credentials இருக்கக்கூடாது. ~/.aws/credentials-ல் production keys இருக்கக்கூடாது, .env-ஐ production-லிருந்து நகலெடுத்திருக்கக்கூடாது, முக்கியமான எதற்கும் write access கொண்ட database password இருக்கக்கூடாது. அந்த agent-க்கு staging அல்லது read-only credential-ஐ மட்டும் வழங்கவும்.
• வரையறுக்கப்பட்ட tokens. ஒரு repository-க்கு மட்டும் கட்டுப்படுத்தப்பட்ட GitHub token-ஐப் பயன்படுத்தவும்; read access போதுமானது என்றால் deploy key-ஐப் பயன்படுத்தவும்.

Claude Code-ல் --dangerously-skip-permissions என்ற flag உள்ளது, இது அதன் பெரும்பாலான அனுமதி கோரும் prompts-ஐத் தவிர்க்கிறது. ஒரு laptop-ல், தற்காலிகமான project-ல் இதைப் பயன்படுத்துவது உங்கள் விருப்பம். ஆனால், tokens உள்ள ஒரு server-ல், தவறாகப் புரிந்துகொள்ளப்பட்ட ஒரு கட்டளைக்கும் git push --force-க்கும் இடையில் இருக்கும் கடைசித் தடையை இது நீக்கிவிடுகிறது. நீங்கள் தவிர்க்கும் அந்த prompts அனைத்தும் "எல்லாம் அல்லது ஒன்றுமில்லை" என்ற நிலையில் இல்லை. மேலும், auto mode இப்போது இயல்பான தொடக்க முறை (Claude Code v2.1.283 முதல்) என்பதால், நீங்கள் கவனிக்காத ஒரு server எந்த permission mode-ல் இருக்க வேண்டும் என்பதை அறிவது அவசியம். இந்த flag உண்மையில் எதை மாற்றுகிறது என்பதையும், built-in sandbox முதல் disposable VPS வரை ஒரு agent-ஐ எவ்வாறு கட்டுப்படுத்துவது என்பதையும் server-ல் Claude Code-ஐப் பாதுகாப்பாக இயக்குதல் பகுதியில் காணலாம்.

Deploy key vs SSH agent forwarding

git உங்கள் laptop-ல் உள்ள key-ஐப் பயன்படுத்த வேண்டும் என்பதற்காக ssh -A செய்வது எளிதானது. ஆனால் அது எதை அனுமதிக்கிறது என்பதைப் புரிந்துகொள்ளுங்கள்: agent forwarding, உங்கள் உள்ளூர் SSH agent-ன் socket-ஐ அந்த server-ல் இயங்கும் user-ன் process-களுக்கு வெளிப்படுத்துகிறது. agent-ஆக இயங்கும் எதுவாக இருந்தாலும், அந்த agent உட்பட, நீங்கள் இணைப்பில் இருக்கும் வரை அது எந்த host-க்கும் உங்கள் key-ஐப் பயன்படுத்தி கையொப்பமிட (sign) கோர முடியும். இது "git இந்த ஒரு repo-வை மட்டும் pull செய்யட்டும்" என்பதை விட மிக அதிகம்.

அதற்குப் பதிலாக, server-லேயே ஒரு key-ஐ உருவாக்கி, அதை ஒரு repository-க்கான deploy key-ஆகப் பதிவு செய்யவும் (agent-க்கு push செய்ய வேண்டிய தேவை இருந்தால் மட்டும் write access வழங்கவும்). மேலும், அந்த server-லிருந்து வரும் commits-களை அடையாளம் காண ஒரு git identity-ஐ அமைக்கவும்:

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 ஏற்கனவே இருந்தால் அதை இணைக்கும், இல்லையெனில் புதியதை உருவாக்கும். எனவே, நாளைத் தொடங்குவதற்கும், இணைப்பு துண்டிக்கப்பட்ட பிறகு மீண்டும் இணைப்பதற்கும் ஒரே கட்டளை போதுமானது. இதற்கு ஒரு alias உருவாக்கவும். ஒரு session-க்குள், Ctrl-b c ஒரு புதிய window-ஐத் திறக்கும், Ctrl-b n மற்றும் Ctrl-b p அவற்றுக்கிடையே மாற உதவும், மேலும் Ctrl-b [ copy mode-க்குச் சென்று பின்னோக்கிச் செல்ல உதவும் (q இதிலிருந்து வெளியேறும்).

நீங்கள் ஒருபோதும் kill செய்யாத sessions குறித்து ஒரு முக்கியமான விஷயம்: ஒவ்வொரு முறையும் agent முழு உரையாடலையும் மீண்டும் அனுப்பும். எனவே, ஒரு வாரத்திற்கு அதை இயங்க விடுவதற்கு முன்பு நீண்ட காலம் இயங்கும் Claude Code session எவற்றிற்கு tokens-ஐச் செலவிடுகிறது என்பதைப் படிக்கவும்.

தோல்வி நிலைகள்

"எனது session காணவில்லை." tmux ls, no server running on /tmp/tmux-1000/default-ஐ அச்சிடுகிறது. இதன் பொருள், அந்த process ஒருபோதும் tmux-க்குள் இயங்கவில்லை என்பதாகும். நீங்கள் SSH மூலம் உள்ளே நுழைந்து, நேரடியாக claude-ஐ இயக்கியுள்ளீர்கள்; இணைப்பு துண்டிக்கப்பட்டவுடன் அதுவும் முடிந்துவிட்டது. இதைத் தவிர்க்கும் பழக்கம்: ஒவ்வொரு முறை login செய்த பிறகும் tmux new -A -s <project>-ஐ முதல் கட்டளையாக இயக்க வேண்டும்.

Pane மிகச்சிறிய பெட்டியாகச் சுருங்குகிறது. window-size விருப்பத்தேர்வு, எந்த இணைக்கப்பட்ட client அளவைத் தீர்மானிக்க வேண்டும் என்பதை முடிவு செய்கிறது. tmux 3.1-க்கு பிறகு (Ubuntu 24.04-ல் 3.4 உள்ளது), இயல்புநிலை latest ஆகும்; இது சமீபத்திய செயல்பாட்டைக் கொண்ட client-ஐக் குறிக்கும். ஆனால், window-size smallest கொண்ட configuration, இணைக்கப்பட்டவற்றில் மிகச்சிறிய client-ன் அளவிற்குச் சுருக்கிவிடும். எனவே, மற்றொரு கணினியிலிருந்து இணைக்கப்பட்ட பழைய client திரையைச் சுருக்கும். நீங்கள் இணையும்போது மற்றவற்றை வெளியேற்ற: tmux attach -d -t claude.

Build Killed-ஐ அச்சிடுகிறது. ஒரே வார்த்தை, stack trace இல்லை. sudo dmesg -T | grep -i -E 'out of memory|killed process' மூலம் உறுதிப்படுத்தவும்; kernel OOM killer மிகப்பெரிய 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 இயங்கிக்கொண்டிருந்தால், அது முழு பயனர் 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-ல் வைக்கவும்: ஒரு இயல்புநிலை tmux pane என்பது login shell ஆகும், இது Ubuntu-வின் ~/.profile வழியாக ~/.bashrc-ஐ அடைகிறது. எந்தவொரு non-login shell-ம் ~/.bashrc-ஐ நேரடியாக வாசிக்கும், எனவே அந்த ஒரு கோப்பு இரண்டையும் உள்ளடக்கும்.

இணைத்த பிறகு நிறங்கள் சிதைந்து காணப்படுகின்றன. TERM பொருந்தவில்லை, மேலே உள்ள default-terminal வரி அதைச் சரிசெய்யும்.

Reboot செய்த பிறகு sessions மறைந்துவிடுகின்றன. இது பிழை அல்ல: tmux server என்பது ஒரு process, reboot செய்யும்போது அது முடிந்துவிடும். uptime-ஐச் சரிபார்க்கவும்.

இது வளரும்போது என்னென்ன சிக்கல்கள் ஏற்படும்

அதிகமான திட்டங்கள். ஒவ்வொரு repository-க்கும் ஒரு tmux session-ஐ உருவாக்கி, அதற்கு அந்த repository-ன் பெயரை வைக்கவும்; tmux ls உங்கள் dashboard-ஆகச் செயல்படும். பெயரிடும் முறையைப் பின்பற்றத் தவறினால், 0, 1, 2 போன்ற குழப்பமான session-கள் உருவாகும். பல session-கள் ஒரே நேரத்தில் இயங்கும்போது, அவை தனித்தனியாக இருக்க வேண்டிய அவசியமில்லை, ஏனெனில் ஒரே பெட்டியில் ஒரு session மற்றொரு session-க்கு செய்தியை அனுப்ப முடியும். ஒரு நீண்ட refactor பணியில் இருக்கும் agent, மற்றொரு session-ஐத் திறந்து சோதனைகளை (tests) இயக்க இது பயனுள்ளதாக இருக்கும். Ports-ம் இதேபோல் பெருகும்; ஆறு repository-களும் :3000-ஐக் கேட்கும்போது, நீங்களே கைமுறையாக port-களை ஒதுக்குவதை நிறுத்திவிட்டு, Docker Compose-ல் Traefik reverse proxy-ஐப் பயன்படுத்தி hostname மூலம் traffic-ஐப் பிரித்து அனுப்பலாம்.

அதிகமான நபர்கள். tmux sockets ஒவ்வொரு பயனருக்கும் தனித்தனியாக இருக்கும். எனவே, ஒரே server-ல் இருக்கும் இரு developers-க்கும் தனித்தனி tmux server-கள் இருக்கும், ஒருவருடைய session-ஐ மற்றவர் பார்க்க முடியாது. ஒரே socket-ஐப் பகிர்ந்து ஒரு session-ஐப் பயன்படுத்தினால், அனைவரும் ஒரே Unix user-ஆக ஒரே shell-ல் தட்டச்சு செய்வார்கள். இது தணிக்கை (audit) மற்றும் அனுமதி (permission) தொடர்பான சிக்கல்களை உருவாக்கும். தனித்தனி பயனர்களை உருவாக்குவதே சரியான மற்றும் பாதுகாப்பான வழி.

கண்காணிப்பற்ற பணிகள். tmux என்பது நீங்கள் இணைக்கக்கூடிய (attach) interactive session-களுக்கானது. யாரும் கவனிக்காத நிலையில், ஒரு கால அட்டவணையின்படி இயங்கும் பணிகளை systemd unit மற்றும் timer-ல் அமைக்க வேண்டும். அங்குதான் அவற்றுக்கு logging, restart policy மற்றும் boot-time survival வசதிகள் தானாகவே கிடைக்கும். cron போன்ற பணிகளை இயக்க tmux-ஐப் பயன்படுத்துவது, அந்தப் பணி ஒரு service-ஆக மாற வேண்டும் என்பதற்கான அறிகுறியாகும்.

கடைசியாக ஒரு குறிப்பு: agent தொடங்கும் dev server-களை 0.0.0.0-ல் அல்லாமல், 127.0.0.1-ல் bind செய்யவும். ufw-ல் ports-ஐத் திறப்பதற்குப் பதிலாக, SSH tunnel (ssh -L 3000:127.0.0.1:3000 agent@your-server) மூலம் அவற்றை அணுகவும். நீங்கள் அரை டஜன் ports-ஐ forward செய்தாலோ அல்லது ஒரு phone மற்றும் laptop இரண்டிலும் ஒரே preview-ஐப் பார்க்க விரும்பினாலோ, அதற்குப் பதிலாக VPS-ல் self-hosted WireGuard VPN-ஐ அமைக்கவும். அப்போது dev server-கள் private interface-ல் bind ஆகும், மேலும் ufw பொதுவான interface-லிருந்து வரும் அனைத்து இணைப்புகளையும் தடுக்கும். firewall-ல் ஓட்டைகளை இடுவதை நிறுத்தினால் மட்டுமே அது பாதுகாப்பாக இருக்கும்.

Claude Code மட்டுமே ஒரே தேர்வு அல்ல: VPS-ல் coding AI agent-ஐ இயக்குவதற்கு Aider மற்றும் Goose ஆகியவையும் சிறந்த மாற்றுகளாக உள்ளன.

FAQ

SSH இணைப்பு துண்டிக்கப்பட்ட பிறகும் Claude Code தொடர்ந்து இயங்குமா?

நீங்கள் அதை tmux-க்குள் தொடங்கினால் மட்டுமே இயங்கும். SSH shell-லிருந்து நேரடியாகத் தொடங்கப்படும் ஒரு process, அந்த shell-ன் child process ஆகும். எனவே, இணைப்பு துண்டிக்கப்படும்போது pty-யுடன் சேர்ந்து அதுவும் முடிந்துவிடும். tmux-க்குள் இருக்கும் shell, detached நிலையில் உள்ள tmux server-க்குச் சொந்தமானது. எனவே, நீங்கள் இணைப்பை மீண்டும் பெறும்போது tmux attach உங்களை அதே scrollback நிலைக்குக் கொண்டு செல்லும். ஒவ்வொரு முறை login செய்த பிறகும் tmux new -A -s <project>-ஐ முதல் கட்டளையாகப் பயன்படுத்தினால், இந்தப் பிரச்சினை வராது.

sudo npm install -g மூலம் CLI-ஐ நான் நிறுவ வேண்டுமா?

கூடாது. root-க்குச் சொந்தமான global prefix-ஐப் பயன்படுத்தினால், பிற்காலத்தில் மென்பொருள்களை நிறுவும்போது EACCES பிழைகளும், npm cache-ல் root-க்குச் சொந்தமான கோப்புகளும் உருவாகும். npm-ன் prefix-ஐ ~/.npm-global என அமைக்கவும் (அல்லது nvm போன்ற version manager-ஐப் பயன்படுத்தவும்). unprivileged agent user-ஆக நிறுவி, ~/.bashrc கோப்பில் interactive guard-க்கு மேலே ~/.npm-global/bin-ஐ PATH-ல் export செய்யவும். நீங்கள் ஏற்கனவே ஒருமுறை sudo npm-ஐ இயக்கியிருந்தால், sudo chown -R $(id -u):$(id -g) ~/.npm மூலம் cache-ஐச் சரிசெய்யவும்.

agent இயங்கும் ஒரு server-ல் ssh -A agent forwarding பாதுகாப்பானதா?

இது அந்தப் பணிக்குத் தேவையானதை விட அதிகமான அனுமதிகளை வழங்குகிறது. Forwarding செய்வதன் மூலம், உங்கள் local SSH agent-ன் socket அந்த user-ஆக இயங்கும் அனைத்து process-களுக்கும் வெளிப்படும். எனவே, நீங்கள் இணைப்பில் இருக்கும் வரை, அந்த server-ல் உள்ள எந்தவொரு process-ம் உங்கள் key-ஐப் பயன்படுத்தி எந்த host-க்கும் கையொப்பமிட முடியும். server-ல் ஒரு ed25519 key-ஐ உருவாக்கி, அதை per-repository deploy key-ஆகப் பதிவு செய்யவும். agent-க்கு push செய்யும் தேவை இருந்தால் மட்டும் write access வழங்கவும்.

எனது build ஏன் Killed என்று மட்டும் காட்டுகிறது?

stack trace இல்லாமல் ஒரே ஒரு வார்த்தை மட்டும் வருவது, kernel-ன் OOM killer-ஆல் அந்த process நிறுத்தப்பட்டதைக் குறிக்கிறது. 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?

நீங்கள் இணைப்பில் இருந்து, கவனித்து, தட்டச்சு செய்யும் interactive session-களுக்கு tmux பொருத்தமானது; agent session-களும் இதற்குள் அடங்கும். யாரும் கவனிக்கத் தேவையில்லாத, குறிப்பிட்ட கால இடைவெளியில் இயங்கும் பணிகளுக்கு systemd unit மற்றும் timer-ஐப் பயன்படுத்த வேண்டும். இதில் logging, restart policy மற்றும் boot-க்கு பிறகும் இயங்கும் வசதி ஆகியவை தானாகவே கிடைக்கும். ஒரு cron-போன்ற பணியைச் செய்ய நீங்கள் tmux-ஐத் தேடுகிறீர்கள் என்றால், அந்தப் பணி ஒரு service-ஆக இருக்க வேண்டும்.