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) சரியான கருவியாகும்.

இயந்திரத்தின் அளவை நிர்ணயித்தல்

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 பயன்பாட்டையும் கவனியுங்கள்: repos, node_modules மற்றும் Docker images ஆகியவை விரைவாக இடத்தைப் பிடிக்கும். உங்கள் toolchain, containers-ஐத் தாண்டி முழுமையான virtual machines, KVM guest, அல்லது local Kubernetes node வரை சென்றால், நீங்கள் தொடங்குவதற்கு முன்பே CPU virtualisation 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

தற்போதைய 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-ஐ நிறுவுதல்

Claude Code என்பது ஒரு Node CLI என்பதால், உங்களுக்கு தற்போதைய Node பதிப்பு தேவை. விநியோக தொகுப்புகள் (distro packages) பெரும்பாலும் பழைய பதிப்புகளாகவே இருக்கும்; Ubuntu மற்றும் Debian-ல் NodeSource பயன்படுத்துவதே வழக்கமான முறையாகும், இது கையொப்பமிடப்பட்ட களஞ்சியத்தை (signed repo) வழங்குகிறது (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 errors) உருவாக்கும் மற்றும் 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 கட்டளை ~/.profile-ல் அல்ல, ~/.bashrc-ல் இருக்க வேண்டும். மேலும், கோப்பின் தொடக்கத்தில் உள்ள "If not running interactively, don't do anything" என்ற பாதுகாப்பு வரிக்கு மேலே இது இருக்க வேண்டும்: tmux சில சமயம் non-login shells-ஐத் தொடங்கும், அவை ~/.bashrc-ஐ வாசிக்கும் ஆனால் ~/.profile-ஐத் தவிர்க்கும், ~/.profile login shells-க்கு மட்டுமே இயங்கும். nvm போன்ற version manager மூலம் பயனருக்கான Node-ஐ நிறுவுவதும் இதே பலனைத் தரும்; எப்படியாயினும், npm install -g-க்கு ஒருபோதும் sudo தேவைப்படக்கூடாது என்பதே இதன் நோக்கம். npm வழக்கம்போல வேலை செய்யும், அல்லது Anthropic-ன் native install script-ஐப் பயன்படுத்தலாம், இதுவே தற்போது ஆவணப்படுத்தப்பட்ட இயல்புநிலை முறையாகும். நீங்கள் கட்டளைகளை நகலெடுக்கும் முன் Anthropic-ன் நிறுவல் ஆவணங்களைச் சரிபார்க்கவும், நிறுவல் முறைகள் மாறக்கூடும்.

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

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

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

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

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

Deploy key மற்றும் SSH agent forwarding ஒப்பீடு

உங்கள் மடிக்கணினியில் உள்ள key-ஐ git பயன்படுத்தும் வகையில் ssh -A செய்வது எளிதானது. ஆனால், அது எதை அனுமதிக்கிறது என்பதைப் புரிந்துகொள்ளுங்கள்: agent forwarding, உங்கள் உள்ளூர் SSH agent-ன் socket-ஐ அந்த server-ல் இயங்கும் செயல்முறைகளுக்கு (processes) வெளிப்படுத்துகிறது. 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 மிகச்சிறிய பெட்டியாகச் சுருங்குகிறது. tmux ஒரு session-ஐ மிகச்சிறிய அளவில் இணைக்கப்பட்டுள்ள 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 இயங்கிக்கொண்டிருந்தால், அது முழு 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" என்ற நிபந்தனைக்குக் கீழே ~/.bashrc-ல் உள்ளது. எனவே, non-interactive shells அதைத் தவிர்க்கின்றன. அந்த export-ஐ நிபந்தனைக்கு மேலே நகர்த்தவும், அதை ~/.profile-ல் வைக்காமல் ~/.bashrc-ல் வைக்கவும்: tmux non-login shells-ஐத் தொடங்கலாம், அவை ~/.bashrc-ஐ வாசிக்கும், ஆனால் ~/.profile-ஐ ஒருபோதும் அணுகாது.

இணைத்த பிறகு நிறங்கள் சிதைந்து காணப்படுகின்றன. இது TERM பொருந்தாமை (mismatch), மேலே உள்ள 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-ஆக இருக்க வேண்டும்.