Remote VPS पर Claude Code कैसे चलाएं: tmux गाइड

समस्या लैपटॉप का ढक्कन है, CLI नहीं

Claude Code आपके लैपटॉप पर तब तक ठीक चलता है जब तक आप उसे बंद नहीं करते: SSH session समाप्त हो जाता है, shell को SIGHUP सिग्नल मिलता है, और टेस्ट रन के बीच में ही agent बंद हो जाता है। CLI को ऐसी मशीन पर चलाएं जो कभी स्लीप मोड में न जाए, और इसे ऐसे terminal multiplexer के अंदर चलाएं जिसकी प्रक्रियाएं आपके SSH session की child processes न हों। यही पूरी तरकीब है, और tmux ही वह मुख्य हिस्सा है जो इस काम को संभव बनाता है, न कि इंस्टॉलेशन।

यह पेज एक ऐसे सर्वर को संचालित करने के बारे में है जिस पर आप agents को चलते हुए छोड़ सकते हैं। यदि आपके पास कोई ऐसा Linux सर्वर नहीं है जिसे आप चालू छोड़ सकें, तो यह जानकारी आपके काम की नहीं है। यही एकमात्र अनिवार्य शर्त है।

tmux वास्तव में क्या करता है

जब आप SSH के जरिए login करते हैं, तो sshd एक shell fork करता है और उसे एक pseudo-terminal सौंप देता है; उस shell से आप जो कुछ भी शुरू करते हैं, वह उसका child process होता है। यदि connection टूट जाए, तो kernel pty को हटा देता है, shell को SIGHUP सिग्नल मिलता है, और वह अपने सभी child processes को बंद कर देता है। इससे foreground में चल रही लंबी प्रक्रियाएं समाप्त हो जाती हैं।

tmux इस स्वामित्व (ownership) को उलट देता है। आपके द्वारा टाइप किया गया tmux कमांड एक thin client है, जो unix socket के माध्यम से एक tmux server से बात करता है। यह server आपके terminal से अलग (detached) होकर चलता है। session के अंदर चलने वाली shells उस server की child होती हैं, न कि sshd की। यदि आप SSH connection काट भी दें, तो client बंद हो जाता है, लेकिन server, session और चल रहे कार्य जारी रहते हैं। दोबारा connect करें, 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। टूलचेन (toolchain) के अनुसार आकार चुनें, न कि CLI के अनुसार। 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

डिस्क पर भी नजर रखें: repos, node_modules और Docker images तेजी से जमा होते हैं। और यदि टूलचेन containers से आगे बढ़कर पूर्ण virtual machines, जैसे कि KVM guest या local Kubernetes node तक पहुँचता है, तो यह सुनिश्चित करें कि plan में CPU virtualisation extensions उपलब्ध हों। ऐसा इसलिए है क्योंकि VPS पर nested virtualization चलाना एक ऐसी सुविधा है जिसे provider आपके लिए enable करता है, न कि ऐसी चीज जिसे आप guest के अंदर से चालू कर सकते हैं।

एक non-root user का निर्माण

एक समर्पित user बनाएँ जिसका अपना home directory हो, और अपनी 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 करके जाँच लें, जबकि password authentication अभी भी fallback के रूप में उपलब्ध है; यदि यह Permission denied (publickey) error देता है, तो समस्या आमतौर पर .ssh directory की ownership या mode में होती है, न कि key में।

जानबूझकर, agent को sudo group में नहीं रखा गया है। यदि किसी system package की आवश्यकता है, तो आप उसे install करें। यह एक निर्णय उन अधिकांश तरीकों को समाप्त कर देता है जिनसे कोई गलत shell command host को नुकसान पहुँचा सकती है।

हमेशा चलने वाले सर्वर के लिए SSH स्वच्छता

सार्वजनिक इंटरनेट पर मौजूद मशीन पर पासवर्ड ऑथेंटिकेशन का उपयोग करना, जिसमें एक एजेंट और आपका सोर्स कोड हो, एक अनावश्यक जोखिम है। इसे बंद कर दें। Ubuntu 24.04 और Debian 13 पर, /etc/ssh/sshd_config में /etc/ssh/sshd_config.d/*.conf शामिल है, इसलिए मुख्य कॉन्फ़िगरेशन को एडिट करने के बजाय एक अलग फ़ाइल बनाएँ:

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

वैलिडेट करें और रिलोड करें। परीक्षण के लिए दूसरे टर्मिनल से एक नया सेशन खोलें, जबकि अपना वर्तमान सेशन खुला रखें:

sudo sshd -t && sudo systemctl restart ssh

Ubuntu 24.04 पर एक सूक्ष्म अंतर: sshd सॉकेट-एक्टिवेटेड है। ऑथेंटिकेशन सेटिंग्स systemctl restart ssh पर लागू होती हैं, लेकिन लिसनिंग Port में बदलाव के लिए systemctl daemon-reload और ssh.socket को रीस्टार्ट करने की भी आवश्यकता होती है।

अब फ़ायरवॉल की बात। SSH को इनेबल करने से पहले उसे अनुमति दें, अन्यथा आप खुद को लॉक कर लेंगे:

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

fail2ban को इस स्पष्ट समझ के साथ इंस्टॉल करें कि यह आपको क्या लाभ देता है: एक बार पासवर्ड ऑथेंटिकेशन बंद हो जाने पर, ब्रूट फ़ोर्स वैसे भी सफल नहीं हो सकता, यह विफल प्रयासों को आपके जर्नल से दूर रखता है।

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

अंत में, sudo apt install unattended-upgrades और sudo dpkg-reconfigure -plow unattended-upgrades के साथ स्वचालित रूप से पैच करें। tmux के साथ इसके इंटरैक्शन पर ध्यान दें: यदि Unattended-Upgrade::Automatic-Reboot चालू है और कर्नल अपडेट होता है, तो बॉक्स रीबूट हो जाएगा और सभी सेशन समाप्त हो जाएंगे। इसे बंद रखें और अपने शेड्यूल के अनुसार रीबूट करें, जब कोई काम बीच में न हो। यही सावधानी रिलीज़ अपग्रेड पर भी लागू होती है: बॉक्स को Ubuntu 24.04 से 26.04 पर ले जाना sshd और कर्नल को रीस्टार्ट करता है, इसलिए इसे ऐसे समय पर करें जब कोई tmux सेशन आपका महत्वपूर्ण काम न संभाल रहा हो।

Ubuntu पर Node.js और Claude Code इंस्टॉल करना

Claude Code एक Node CLI है, इसलिए आपको एक आधुनिक Node वर्ज़न की आवश्यकता है। Distro पैकेज अक्सर पुराने होते हैं; 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-owned ग्लोबल प्रीफिक्स बाद में permission errors पैदा करता है और npm cache में root-owned फाइलें छोड़ देता है। सबसे पहले npm के प्रीफिक्स को यूजर की होम डायरेक्टरी पर सेट करें:

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" गार्ड के ऊपर होना चाहिए: tmux नॉन-लॉगिन शेल्स शुरू कर सकता है, जो ~/.bashrc को पढ़ते हैं और ~/.profile को छोड़ देते हैं, जबकि ~/.profile केवल लॉगिन शेल्स के लिए चलता है। nvm जैसे वर्ज़न मैनेजर के माध्यम से प्रति-यूजर Node का उपयोग करना भी यही परिणाम देता है; किसी भी स्थिति में लक्ष्य यह है कि npm install -g को कभी भी sudo की आवश्यकता न पड़े। npm अभी भी ठीक काम करता है, या Anthropic की नेटिव इंस्टॉल स्क्रिप्ट का उपयोग करें, जो वर्तमान में प्रलेखित डिफ़ॉल्ट है। पेस्ट करने से पहले Anthropic के इंस्टॉल डॉक्यूमेंटेशन की जाँच करें, क्योंकि इंस्टॉल करने के तरीके बदलते रहते हैं।

इसे शुरू करने के लिए किसी रिपॉजिटरी के अंदर claude चलाएँ। पहली बार चलाने पर यह आपको ऑथेंटिकेशन की प्रक्रिया से ले जाएगा; एक हेडलेस बॉक्स में ब्राउज़र नहीं होता है, इसलिए यह प्रक्रिया आपको एक URL देती है जिसे आपको अपनी मशीन पर खोलना होता है और एक कोड जिसे टर्मिनल में वापस लाना होता है। (एनवायरनमेंट में API key का उपयोग करना दूसरा तरीका है।) किसी भी तरह से, वह क्रेडेंशियल अब सर्वर पर रहता है, जो हमें उस हिस्से पर लाता है जिसे लोग छोड़ देते हैं।

ब्लास्ट रेडियस (blast radius) पर चर्चा

शेल एक्सेस वाला एजेंट एक शेल ही होता है। यह उस यूजर के रूप में सब कुछ पढ़ सकता है जिसके रूप में यह चलता है, और वहां डेटा भेज (push) सकता है जहां वह यूजर भेज सकता है। यह टूल की आलोचना नहीं है, बल्कि इसकी परिभाषा है, और यही कारण है कि यह जिस अकाउंट के तहत चलता है, वह किसी भी व्यक्तिगत सेटिंग से अधिक महत्वपूर्ण है।

• समर्पित, अनप्रिविलेज्ड (unprivileged) यूजर। कोई sudo ग्रुप नहीं, और न ही आपके अपने अकाउंट के साथ कोई होम डायरेक्टरी साझा होनी चाहिए।
• बॉक्स पर कोई प्रोडक्शन क्रेडेंशियल न रखें। कोई ~/.aws/credentials नहीं जिसमें प्रोडक्शन कीज़ हों, कोई .env नहीं जिसे प्रोडक्शन से कॉपी किया गया हो, और न ही ऐसा कोई डेटाबेस पासवर्ड जिसमें किसी महत्वपूर्ण चीज़ का राइट एक्सेस हो। एजेंट को केवल स्टेजिंग या रीड-ओनली क्रेडेंशियल दें।
• स्कोप वाले टोकन। एक फाइन-ग्रेन्ड GitHub टोकन जो केवल एक रिपॉजिटरी तक सीमित हो; या एक डिप्लॉय की (deploy key) जब केवल रीड एक्सेस पर्याप्त हो।

Claude Code में एक फ्लैग होता है जो इसके परमिशन प्रॉम्प्ट्स को पूरी तरह से स्किप कर देता है। लैपटॉप पर, किसी अस्थायी प्रोजेक्ट के लिए, यह आपका निर्णय है। टोकन रखने वाले सर्वर पर, यह गलत तरीके से पढ़े गए निर्देश और git push --force के बीच की अंतिम बाधा को हटा देता है। जिन प्रॉम्प्ट्स को आप स्किप कर रहे हैं, वे 'सब या कुछ नहीं' (all-or-nothing) वाले नहीं हैं, और ऑटो मोड के नए डिफ़ॉल्ट के रूप में आने के साथ, यह जानना महत्वपूर्ण है कि जिस सर्वर पर आप नज़र नहीं रख रहे हैं, उसे किस परमिशन मोड पर पिन किया जाना चाहिए। यह फ्लैग वास्तव में क्या बदलता है, और इसके साथ चलने वाले एजेंट को कैसे नियंत्रित किया जाए (इन-बिल्ट सैंडबॉक्स से लेकर डिस्पोजेबल VPS तक), यह सर्वर पर सुरक्षित रूप से Claude Code चलाने में कवर किया गया है।

डिप्लॉय की (deploy key) बनाम SSH एजेंट फॉरवर्डिंग

ssh -A का उपयोग करना आकर्षक लगता है ताकि git आपके लैपटॉप पर मौजूद की (key) का उपयोग कर सके। समझें कि यह क्या अनुमति देता है: एजेंट फॉरवर्डिंग आपके स्थानीय SSH एजेंट के सॉकेट को बॉक्स पर उस यूजर के रूप में चलने वाली प्रक्रियाओं के लिए एक्सपोज़ कर देता है। agent के रूप में चलने वाली कोई भी चीज़, जिसमें एजेंट भी शामिल है, आपके की से किसी भी ऐसे होस्ट के लिए साइन करने को कह सकती है जिस तक वह पहुँच सकता है, बशर्ते आप कनेक्टेड रहें। यह "git को केवल एक रिपो पुल करने दें" से कहीं अधिक है।

इसके बजाय सर्वर पर एक की (key) जनरेट करें, इसे प्रति-रिपॉजिटरी डिप्लॉय की के रूप में रजिस्टर करें (यदि एजेंट को पुश करने की आवश्यकता हो तभी राइट एक्सेस दें), और एक git आइडेंटिटी सेट करें ताकि बॉक्स से किए गए कमिट पहचाने जा सकें:

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 वह कमांड है जिसे याद रखना चाहिए। यदि सेशन मौजूद है तो यह उससे जुड़ जाता है, और यदि नहीं है तो यह उसे बना देता है। इस प्रकार, एक ही कमांड दिन की शुरुआत करने और डिस्कनेक्ट होने के बाद फिर से जुड़ने, दोनों के काम आती है। इसका एक alias बना लें। सेशन के अंदर, Ctrl-b c एक विंडो खोलता है, Ctrl-b n और Ctrl-b p उनके बीच स्विच करते हैं, और Ctrl-b [ स्क्रॉल करने के लिए कॉपी मोड में प्रवेश करता है (q से बाहर निकलते हैं)।

उन सेशन्स के बारे में एक बात ध्यान रखें जिन्हें आप कभी बंद (kill) नहीं करते: एजेंट हर टर्न पर पूरी बातचीत को फिर से भेजता है। इसलिए, किसी सेशन को एक सप्ताह तक खुला छोड़ने से पहले एक लंबे समय तक चलने वाला Claude Code सेशन अपने टोकन कहाँ खर्च करता है के बारे में पढ़ें।

विफलता के प्रकार (Failure modes)

"मेरा सेशन गायब हो गया है।" tmux ls, no server running on /tmp/tmux-1000/default प्रिंट करता है। इसका सीधा अर्थ यह है कि प्रोसेस कभी tmux के अंदर थी ही नहीं। आपने SSH किया, सीधे claude चलाया और डिस्कनेक्ट होते ही वह प्रोसेस समाप्त हो गई। इसे रिकवर करने का कोई तरीका नहीं है। इससे बचने की आदत: हर लॉगिन के बाद tmux new -A -s <project> पहली कमांड होनी चाहिए।

पेन (pane) एक छोटे बॉक्स में सिकुड़ जाता है। tmux एक सेशन का आकार सबसे छोटे अटैच्ड क्लाइंट के अनुसार निर्धारित करता है। यदि किसी अन्य मशीन से कोई पुराना क्लाइंट अभी भी अटैच्ड है, तो वह डिस्प्ले को सिकोड़ देता है। अटैच करते समय दूसरों को फोर्सफुली हटा दें: tmux attach -d -t claude।

एक बिल्ड Killed प्रिंट करता है। केवल एक शब्द, कोई स्टैक ट्रेस नहीं। sudo dmesg -T | grep -i -E 'out of memory|killed process' के साथ पुष्टि करें, कर्नल OOM किलर ने सबसे बड़ी प्रोसेस को चुन लिया है। Node से आपको इसके बजाय FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory दिख सकता है। समाधान, क्रम में: स्वैप (swap) जोड़ें (ऊपर देखें), टेस्ट और कंपाइलर की पैरेललिज्म को सीमित करें, NODE_OPTIONS=--max-old-space-size=... के साथ Node का हीप बढ़ाएं, या VPS का साइज बढ़ाएं। OOM किलर बिल्ड के बजाय tmux सर्वर को भी चुन सकता है, जिससे आपका सेशन भी समाप्त हो जाएगा; यदि systemd-oomd चल रहा है, तो यह पूरे यूजर स्लाइस को समाप्त कर सकता है जिसका प्रभाव समान होगा।

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'। रूट-ओन्ड प्रीफिक्स में ग्लोबल इंस्टॉलेशन। ऊपर दिए गए ~/.npm-global प्रीफिक्स का उपयोग करें। यदि आपने पहले कभी sudo npm चलाया है तो आपको Your cache folder contains root-owned files भी दिख सकता है, इसे sudo chown -R $(id -u):$(id -g) ~/.npm से ठीक करें।

claude: command not found, लेकिन केवल कभी-कभी। आपका PATH एक्सपोर्ट नीचे ~/.bashrc में "If not running interactively, don't do anything" गार्ड के नीचे स्थित है, इसलिए नॉन-इंटरैक्टिव शेल इसे छोड़ देते हैं। एक्सपोर्ट को उस गार्ड के ऊपर ले जाएं और इसे ~/.bashrc में रखें, ~/.profile में नहीं: tmux नॉन-लॉगिन शेल शुरू कर सकता है, जो ~/.bashrc को पढ़ते हैं और कभी ~/.profile तक नहीं पहुँचते।

अटैच करने के बाद रंग खराब दिखना। यह TERM का बेमेल होना है, ऊपर दी गई default-terminal लाइन इसका समाधान है।

रीबूट के बाद सेशन गायब हो जाते हैं। यह कोई बग नहीं है: tmux सर्वर एक प्रोसेस है और रीबूट उसे समाप्त कर देता है। uptime की जाँच करें।

जैसे-जैसे यह बढ़ता है, क्या खराब होता है

अधिक प्रोजेक्ट्स। प्रति रेपो एक tmux session रखें, जिसका नाम उसी के आधार पर हो; tmux ls तब आपका डैशबोर्ड होता है। यदि आप नामकरण के अनुशासन का पालन नहीं करते हैं, तो आपको 0, 1, 2 जैसे sessions मिलेंगे। जब कई sessions एक साथ चल रहे हों, तो उन्हें अलग-थलग काम करने की आवश्यकता नहीं होती, क्योंकि एक ही बॉक्स पर एक session दूसरे को संदेश भेज सकता है, जो तब उपयोगी होता है जब एक लंबे refactor पर काम कर रहा agent दूसरे को tests चलाने के लिए कहना चाहता है। Ports भी इसी तरह फैलते हैं, छह repos जो सभी :3000 चाहते हैं, वह बिंदु है जहाँ आपको उन्हें मैन्युअल रूप से असाइन करना बंद कर देना चाहिए और Docker Compose के साथ Traefik reverse proxy को hostname के आधार पर dispatching करने देना चाहिए।

अधिक लोग। tmux sockets प्रति-उपयोगकर्ता (per-user) होती हैं, इसलिए एक ही बॉक्स पर दो डेवलपर्स को अपना-अपना tmux server मिलता है और वे एक-दूसरे के sessions नहीं देख सकते। एक shared socket पर एक session साझा करने का मतलब है कि हर कोई एक ही Unix user के रूप में एक ही shell में टाइप कर रहा है, जिसके ऑडिट और अनुमति संबंधी परिणाम होते हैं। अलग-अलग users का उपयोग करना ही उबाऊ लेकिन सही तरीका है।

अनिर्धारित कार्य (Unattended work)। tmux उन interactive sessions के लिए है जिनसे आप जुड़ते हैं। जो कार्य बिना किसी की निगरानी के schedule पर चलते हैं, उन्हें systemd unit और timer में होना चाहिए, जहाँ उन्हें logging, restart policy और boot survival की सुविधा मुफ्त में मिलती है। cron-जैसे कार्य को चलाने के लिए tmux का उपयोग करना इस बात का संकेत है कि उस कार्य को एक service के रूप में चलना चाहिए।

एक अंतिम बात, agent द्वारा शुरू किए गए dev servers को 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 कर रहे हों, या एक फोन और एक लैपटॉप दोनों एक ही preview चाहते हों, तो उनके सामने VPS पर self-hosted WireGuard VPN लगा दें: dev servers एक private interface पर bind होते हैं, और ufw public interface से आने वाले सभी traffic को रोकता रहता है। firewall केवल तभी मदद करता है जब आप उसमें छेद करना बंद कर दें।

Claude Code ही एकमात्र विकल्प नहीं है: VPS पर coding AI agent चलाना Aider और Goose को भी एक विकल्प बनाता है।

FAQ

क्या SSH connection टूटने के बाद भी Claude Code चलता रहता है?

केवल तभी, यदि आपने इसे tmux के अंदर शुरू किया हो। सीधे SSH shell से शुरू की गई process उस shell की child होती है और connection टूटने पर pty के साथ ही समाप्त हो जाती है। tmux के अंदर, shell detached tmux server का हिस्सा होती है, इसलिए agent अपना काम जारी रखता है और tmux attach आपको वापस उसी scrollback पर ले आता है। हर login के बाद tmux new -A -s <project> को अपनी पहली command बनाएँ, इससे यह समस्या हल हो जाएगी।

क्या मुझे CLI को sudo npm install -g के साथ install करना चाहिए?

नहीं। root-owned global prefix भविष्य में install करते समय EACCES errors और npm cache में root-owned files की समस्या पैदा करता है। npm के prefix को ~/.npm-global पर सेट करें (या 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 को repair करें।

क्या agent चलाने वाले server पर ssh -A agent forwarding सुरक्षित है?

यह काम की जरूरत से कहीं अधिक अधिकार देता है। Forwarding आपके local SSH agent के socket को उस user के रूप में चल रही हर process के लिए expose कर देता है। इसलिए, जब तक आप connected हैं, server पर मौजूद कोई भी process आपके key का उपयोग करके किसी भी host के लिए sign कर सकती है। server पर एक ed25519 key generate करें और उसे per-repository deploy key के रूप में register करें, जिसमें write access तभी दें यदि agent को वास्तव में push करना हो।

मेरा 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 का size बढ़ाएँ। ध्यान रखें कि OOM killer build के बजाय tmux server को चुन सकता है, जिससे आपका पूरा session बंद हो जाएगा।

tmux या systemd service?

tmux उन interactive sessions के लिए उपयुक्त है जिन्हें आप देखते हैं, जिनसे जुड़ते हैं और जिनमें type करते हैं; एक agent session बिल्कुल ऐसा ही होता है। जो काम बिना किसी की निगरानी के schedule पर चलता है, उसे systemd unit और timer में होना चाहिए, जहाँ logging, restart policy और boot के बाद भी चलते रहने की सुविधा स्वतः मिलती है। यदि आप cron-shaped job चलाने के लिए tmux का उपयोग कर रहे हैं, तो उस job को एक service होना चाहिए।