remote VPS پر Claude Code tmux میں چلائیں

مسئلہ لیپ ٹاپ کا ڈھکنا ہے، CLI نہیں

Claude Code آپ کے لیپ ٹاپ پر ٹھیک چلتا رہتا ہے جب تک آپ اسے بند نہیں کرتے: SSH سیشن ختم ہو جاتا ہے، shell کو SIGHUP موصول ہوتا ہے، اور ٹیسٹ چلانے کے تین منٹ بعد ایجنٹ بھی اسی کے ساتھ مر جاتا ہے۔ CLI ایک ایسی مشین پر چلائیں جو کبھی نہ سوئے، ایک terminal multiplexer کے اندر جس کے عمل آپ کے SSH سیشن کے children نہ ہوں۔ یہی پوری ترکیب ہے — اور tmux، نصب نہیں، وہ بنیادی حصہ ہے۔

یہ صفحہ ایک ایسی مشین کو چلانے کے بارے میں ہے جس پر آپ ایجنٹس چلتے چھوڑتے ہیں۔ اگر آپ کے پاس کوئی Linux سرور نہیں ہے جسے آپ آن چھوڑ سکیں، تو یہاں سے کچھ بھی لاگو نہیں ہوتا۔ یہی ایک حقیقی شرط ہے۔

tmux دراصل کیا کرتا ہے

جب آپ SSH سے داخل ہوتے ہیں، تو sshd ایک shell فورک کرتا ہے اور اسے ایک pseudo-terminal دیتا ہے۔ اس shell سے جو بھی آپ چلائیں، وہ اس کا child ہوتا ہے۔ کنکشن منقطع ہو تو kernel pty کو ختم کر دیتا ہے، shell کو SIGHUP موصول ہوتا ہے، اور وہ اپنے children کو باری باری hangup کر دیتا ہے۔ طویل چلنے والے foreground پروسیس مر جاتے ہیں۔

tmux ملکیت کا رخ پلٹ دیتا ہے۔ آپ جو tmux کمانڈ ٹائپ کرتے ہیں، وہ ایک پتلا کلائنٹ ہے جو ایک unix socket کے ذریعے tmux server سے بات کرتا ہے جو آپ کے ٹرمینل سے detached چلتا ہے۔ ایک سیشن کے اندر کے shells اس server کے children ہوتے ہیں، sshd کے نہیں۔ SSH کنکشن ختم کریں تو کلائنٹ غائب ہو جاتا ہے، جبکہ server، سیشن اور کام کے درمیان موجود ایجنٹ چلتا رہتا ہے۔ دوبارہ کنیکٹ کریں، tmux attach، اور آپ اسی shell میں اسی scrollback کے ساتھ واپس ہیں۔ nohup بھی hangup سے بچ جاتا ہے، لیکن واپس داخل ہونے کا کوئی راستہ نہیں دیتا — آپ کسی backgrounded TUI سے دوبارہ attach نہیں ہو سکتے۔ Claude Code انٹرایکٹو ہے؛ tmux (یا screen) درست ٹول ہے۔

بکس کا سائز متعین کرنا

CLI ایک Node عمل ہے۔ یہ مشین کو بھرنے والی چیز نہیں ہے۔ مشین کو جو بھرتا ہے وہ وہ سب کچھ ہے جو ایجنٹ آپ کی طرف سے چلاتی ہے: ایک build، مکمل ٹیسٹ سوٹ، tsc، ایک زبان سرور، Docker میں کوئی ڈیٹا بیس۔ سائز 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

ڈسک کو بھی دیکھیں: repos، node_modules اور Docker امیجز تیزی سے جمع ہوتے ہیں۔ اور اگر toolchain کنٹینرز سے آگے بڑھ کر مکمل ورچوئل مشینوں تک جاتی ہے — ایک KVM گیسٹ، ایک مقامی Kubernetes نوڈ — تو خریدنے سے پہلے چیک کریں کہ پلان CPU virtualisation extensions کو ظاہر کرتا ہے، کیونکہ VPS پر nested virtualization چلانا وہ چیز ہے جو فراہم کنندہ آپ کے لیے فعال کرتا ہے، نہ کہ وہ جو آپ گیسٹ کے اندر سے آن کرتے ہیں۔

سب سے پہلے غیر روٹ صارف

ایک مخصوص صارف بنائیں جس کا اپنا ہوم ہو، اور اپنی پبلک کلید کو درج ذیل میں رکھیں:

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

جان بوجھ کر، agent کو sudo گروپ میں شامل نہیں کیا گیا۔ اگر کسی سسٹم پیکیج کی ضرورت ہو، تو آپ اسے انسٹال کریں۔ یہ ایک فیصلہ ان تمام طریقوں کو ختم کر دیتا ہے جن سے کوئی بھٹکا ہوا شیل کمانڈ ہوسٹ کو تباہ کر سکتی ہے۔

ایک ایسے سرور کے لیے 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 کو اس بات کی واضح سمجھ کے ساتھ انسٹال کریں کہ یہ آپ کو کیا فائدہ دیتا ہے: پاس ورڈ سے توثیق بند ہونے کے بعد بہرحال brute force کامیاب نہیں ہو سکتا — یہ صرف ناکام کوششوں کو آپ کے جرنل سے باہر رکھتا ہے۔

# /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 پر Node.js اور Claude Code انسٹال کریں

Claude Code ایک Node CLI ہے، اس لیے آپ کو موجودہ Node کی ضرورت ہے۔ ڈسٹرو پیکیج اکثر پیچھے رہ جاتا ہے؛ Ubuntu اور Debian پر NodeSource معمول کا راستہ ہے، اور یہ ایک سائن شدہ ریپو فراہم کرتا ہے (کوئی 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 کے ساتھ نہیں۔ روٹ کی ملکیت والا گلوبل پریفیکس بعد میں پرمیشن ایررز پیدا کرتا ہے اور npm کیش میں روٹ کی ملکیت والی فائلیں چھوڑتا ہے۔ پہلے 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

ایکسپورٹ ~/.bashrc میں جاتا ہے، ~/.profile میں نہیں، اور یہ فائل کے اوپری حصے کے قریب "If not running interactively, don't do anything" گارڈ کے اوپر آتا ہے: tmux غیر-لاگن شیلز شروع کر سکتا ہے، جو ~/.bashrc پڑھتے ہیں اور ~/.profile کو چھوڑ دیتے ہیں — ~/.profile صرف لاگن شیلز کے لیے چلتا ہے۔ nvm جیسے ورژن مینیجر کے ذریعے فی-یوزر Node بھی یہی کام کرتا ہے؛ Either way مقصد یہ ہے کہ npm install -g کو کبھی sudo کی ضرورت نہ پڑے۔ npm اب بھی ٹھیک کام کرتا ہے، یا Anthropic کا نیٹو انسٹال سکرپٹ استعمال کریں، جو فی الحال دستاویزی ڈیفالٹ ہے۔ پیسٹ کرنے سے پہلے Anthropic کے انسٹال دستاویزات چیک کریں — انسٹال طریقے بدل جاتے ہیں۔

کسی ریپو کے اندر اسے شروع کرنے کے لیے claude چلائیں۔ پہلی چلان آپ کو تصدیق کے مراحل سے گزرتی ہے؛ ہیڈلیس باکس میں کوئی براؤزر نہیں ہوتا، اس لیے یہ عمل آپ کو اپنی مشین پر کھولنے کے لیے ایک URL دیتا ہے اور ٹرمینل پر واپس لانے کے لیے ایک کوڈ دیتا ہے۔ (ماحول میں API کلید دوسرا راستہ ہے۔) Either way، وہ اسناد اب سرور پر موجود ہیں — جو ہمیں اس حصے پر لاتا ہے جسے لوگ چھوڑ دیتے ہیں۔

اثر کی حد کا بحث

شیل تک رسائی رکھنے والا ایجنٹ دراصل شیل ہی ہوتا ہے۔ یہ اس صارف کا ہر وہ ڈیٹا پڑھ سکتا ہے جو اس صارف کے پڑھنے کے قابل ہو، اور وہاں push کر سکتا ہے جہاں وہ صارف push کر سکتا ہو۔ یہ ٹول کی تنقید نہیں ہے، یہ اس کی تعریف ہے — اور اسی لیے جس اکاؤنٹ کے تحت یہ چلتا ہے، وہ کسی بھی انفرادی ترتیب سے زیادہ اہم ہوتا ہے۔

• مخصوص، غیر مرتبہ صارف۔ کوئی sudo گروپ نہیں، آپ کے اپنے اکاؤنٹ کے ساتھ شیئر کیا گیا کوئی ہوم ڈائریکٹری نہیں۔
• سرور پر پروڈکشن کی کوئی اسناد نہیں۔ کوئی ~/.aws/credentials جس میں پروڈکشن کی چابیاں ہوں نہیں، پروڈکشن سے copy کی گئی کوئی .env نہیں، اور ایسا کوئی ڈیٹا بیس پاس ورڈ نہیں جسے کسی بھی اہم چیز تک write رسائی ہو۔ ایجنٹ کو staging یا صرف پڑھنے کے قابل اسناد دیں۔
• محدود ٹوکن۔ ایک fine-grained GitHub ٹوکن جو صرف ایک ریپوزٹری تک محدود ہو؛ ایک deploy key جب صرف پڑھنے کی رسائی کافی ہو۔

Claude Code ایک flag فراہم کرتا ہے جو اس کے permission prompts کو مکمل طور پر نظر انداز کر دیتا ہے۔ لیپ ٹاپ پر، کسی عارضی پروجیکٹ پر، یہ آپ کا فیصلہ ہے۔ لیکن ٹوکن رکھنے والے سرور پر، یہ ایک غلط پڑھے گئے instruction اور git push --force کے درمیان حائل آخری رکاوٹ کو ختم کر دیتا ہے۔ یہ flag دراصل کیا تبدیل کرتا ہے، اور اس کے ساتھ چلنے والے ایجنٹ کو کیسے محدود رکھا جائے، built-in sandbox سے لے کر ایک قابلِ ضبط VPS تک، اسے سرور پر Claude Code کو محفوظ طریقے سے چلانا میں بیان کیا گیا ہے۔

Deploy key بمقابلہ SSH agent forwarding

یہ پرکشش ہے کہ ssh -A کیا جائے تاکہ git آپ کی لیپ ٹاپ پر موجود چابی استعمال کر سکے۔ سمجھیں کہ یہ کیا اختیارات دیتا ہے: agent forwarding آپ کے مقامی SSH agent کے socket کو سرور پر اس صارف کے طور پر چلنے والے processes کے لیے دستیاب کر دیتا ہے۔ agent کے طور پر چلنے والی کوئی بھی چیز — بشمول ایجنٹ — آپ کی چابی سے کہہ سکتی ہے کہ وہ کسی بھی ایسے host کے لیے sign کرے جس تک وہ پہنچ سکے، جب تک آپ connected رہیں۔ یہ "git کو صرف یہ ایک ریپوزٹری pull کرنے دیں" سے کہیں زیادہ ہے۔

اس کے بجائے سرور پر ایک چابی بنائیں، اسے ایک per-repository deploy key کے طور پر register کریں (write رسائی صرف اس وقت دیں جب ایجنٹ کو push کرنے کی ضرورت ہو)، اور ایک git identity مقرر کریں تاکہ سرور سے کیے گئے commits پہچانے جا سکیں:

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 وہ کمانڈ ہے جسے یاد رکھنا چاہیے — یہ سیشن موجود ہونے کی صورت میں منسلک ہو جاتی ہے اور موجود نہ ہونے کی صورت میں اسے بنا دیتی ہے، لہٰذا ایک ہی کمانڈ دن کا آغاز اور منقطع ہونے کے بعد دوبارہ شروع کرنے دونوں کو پورا کرتی ہے۔ اس کا ایلیاس بنائیں۔ سیشن کے اندر، Ctrl-b c ایک ونڈو کھولتا ہے، Ctrl-b n اور Ctrl-b p ان کے درمیان منتقل ہوتے ہیں، اور Ctrl-b [ کاپی موڈ میں داخل ہوتا ہے تاکہ پیچھے سکرول کیا جا سکے (q اس سے باہر نکلتا ہے)۔

ان سیشنز کے بارے میں جاننا ضروری ہے جنہیں آپ کبھی ختم نہیں کرتے: ایجنٹ ہر باری پر پوری گفتگو دوبارہ بھیجتا ہے، لہٰذا کسی ایسے سیشن کو ایک ہفتے کے لیے چلے چھوڑنے سے پہلے ایک طویل عرصے تک چلنے والا Claude Code سیشن اپنے ٹوکنز کہاں خرچ کرتا ہے پڑھیں۔

ناکامی کے طریقے

"میرا سیشن غائب ہو گیا۔" tmux ls no server running on /tmp/tmux-1000/default چھاپتا ہے۔ یہ تقریباً ہمیشہ اس کا مطلب ہوتا ہے کہ عمل کبھی tmux کے اندر نہیں تھا — آپ نے SSH سے داخل ہو کر claude براہ راست چلایا، اور منقطعی نے اسے ختم کر دیا۔ بحال کرنے کے لیے کچھ نہیں۔ اسے روکنے والی عادت: ہر لاگ ان کے بعد tmux new -A -s <project> سب سے پہلا کمانڈ ہے۔

پین ایک چھوٹے سے خانے میں سکڑ جاتا ہے۔ 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 کے ہیپ کو NODE_OPTIONS=--max-old-space-size=... سے بڑھائیں، یا VPS کا سائز بڑھائیں۔ OOM کِلر بلڈ کے بجائے tmux سرور کو بھی منتخب کر سکتا ہے، جس سے آپ کا سیشن بھی چلا جاتا ہے؛ اگر systemd-oomd چل رہا ہے، تو یہ ایک پورا یوزر سلیس کو بھی ختم کر سکتا ہے جس کا اثر وہی ہوتا ہے۔

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'۔ root کی ملکیت والے prefix میں عالمی انسٹالیشن۔ اوپر دیا گیا ~/.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 ایکسپورٹ ~/.bashrc میں "اگر انٹرایکٹو طور پر نہیں چل رہا ہے تو کچھ نہ کریں" گارڈ کے نیچے ہے، اس لیے غیر انٹرایکٹو شیلز اسے چھوڑ دیتی ہیں۔ ایکسپورٹ کو اس گارڈ کے اوپر لے جائیں اور اسے ~/.bashrc میں رکھیں، ~/.profile میں نہیں: tmux غیر-لاگ ان شیلز شروع کر سکتا ہے، جو ~/.bashrc پڑھتی ہیں اور ~/.profile کو کبھی چھوتی نہیں۔

منسلک ہونے کے بعد رنگ بگڑ جاتے ہیں۔ ایک TERM بے میلانی — اوپر دی گئی default-terminal لائن ہی حل ہے۔

ریبوٹ کے بعد سیشنز غائب ہو جاتے ہیں۔ یہ کوئی بگ نہیں ہے: tmux سرور ایک عمل ہے، اور ریبوٹ اسے ختم کر دیتا ہے۔ uptime دیکھیں۔

بڑھنے کے ساتھ کیا ٹوٹتا ہے

مزید پروجیکٹس۔ ہر ریپوزیٹری کے لیے ایک tmux سیشن، اس کے نام کے ساتھ؛ پھر tmux ls آپ کا ڈیش بورڈ ہے۔ نام رکھنے کی نظم و ضبط چھوڑ دیں تو آپ کو سیشنز 0، 1، 2 مل جائیں گے۔ پورٹس بھی اسی طرح پھیلتے ہیں — چھ ریپوزیٹریز سب :3000 چاہتے ہیں، یہ وہ مقام ہے جہاں انہیں ہاتھ سے تفویض کرنا بند کریں اور کام a Traefik reverse proxy route multiple apps under Docker Compose کو ہوسٹ نام کے ذریعے بھیجنے کا حکم دیں۔

مزید لوگ۔ tmux ساکٹس فی یوزر ہوتے ہیں، اس لیے ایک ہی باکس پر دو ڈویلپرز کو اپنا الگ tmux سرور ملتا ہے اور وہ ایک دوسرے کے سیشنز نہیں دیکھ سکتے۔ ایک مشترکہ ساکٹ پر ایک سیشن شیئر کرنے کا مطلب ہے کہ سب ایک ہی Unix یوزر کی حیثیت سے ایک ہی شیل میں ٹائپ کرتے ہیں، جس کے آڈٹ اور اجازت کے نتائج ہوتے ہیں۔ الگ الگ یوزرز ہونا ایک سادہ، درست جواب ہے۔

بغیر نگرانی کا کام۔ tmux ان انٹرایکٹو سیشنز کے لیے ہے جن سے آپ منسلک ہوتے ہیں۔ شیڈول پر چلنے والے کام جنہیں کوئی نہیں دیکھ رہا، وہ ایک systemd یونٹ اور ٹائمر میں رکھنے کے قابل ہیں، جہاں انہیں لاگنگ، ری اسٹارٹ پالیسی اور بوت سروائیول مفت ملتی ہے۔ cron نما کام چلانے کے لیے tmux کی طرف بڑھنا اس بات کا اشارہ ہے کہ کام ایک سروس بننا چاہتا ہے۔

آخری بات: ایجنٹ جو dev سرورز شروع کرتا ہے انہیں 127.0.0.1 سے بائنڈ کریں، 0.0.0.0 سے نہیں، اور ان تک SSH ٹنل (ssh -L 3000:127.0.0.1:3000 agent@your-server) کے ذریعے پہنچیں، ufw میں پورٹس کھولنے کے بجائے۔ ایک بار جب آپ آدھی درجن پورٹس فارورڈ کر رہے ہوں، یا ایک فون اور لیپ ٹاپ دونوں ایک ہی پریویو تک رسائی چاہیں، تو ان کے سامنے ایک self-hosted WireGuard VPN on the VPS لگا دیں: dev سرورز ایک پرائیویٹ انٹرفیس سے بائنڈ ہوتے ہیں، اور ufw پبلک انٹرفیس سے سب کچھ مسترد کرتا رہتا ہے۔ فائر وال تب ہی مدد کرتا ہے جب آپ اس میں سوراخ کرنا بند کر دیں۔

Claude Code واحد انتخاب نہیں ہے: running a coding AI agent on a VPS میں Aider اور Goose کا بھی موازنہ کیا گیا ہے۔

FAQ

کیا Claude Code میری SSH کنکشن ٹوٹنے کے بعد بھی چلتا رہتا ہے؟

صرف اس صورت میں جب آپ نے اسے tmux کے اندر شروع کیا ہو۔ SSH شیل سے براہ راست شروع کیا گیا کوئی پروسیس اس شیل کا چائلڈ ہوتا ہے اور کنکشن ختم ہونے پر pty کے ساتھ مر جاتا ہے۔ tmux کے اندر شیل ایک الگ (detached) tmux server سے تعلق رکھتی ہے، اس لیے ایجنٹ کام کے درمیان کام کرتا رہتا ہے اور tmux attach آپ کو اسی اسکرول بیک میں واپس لے آتا ہے۔ ہر لاگ ان کے بعد tmux new -A -s <project> کو پہلا کمانڈ بنائیں اور یہ مسئلہ ختم ہو جائے گا۔

کیا مجھے CLI کو sudo npm install -g کے ساتھ انسٹال کرنا چاہیے؟

نہیں۔ root کی ملکیت والا گلوبل پریفکس آپ کو بعد کی انسٹالیشنز پر EACCES errors دیتا ہے اور npm کیش میں root کی ملکیت والی فائلیں بنتا ہے۔ npm کے پریفکس کو ~/.npm-global پر سیٹ کریں (یا nvm جیسا کوئی version manager استعمال کریں)، غیر مراعات یافتہ agent user کے طور پر انسٹال کریں، اور ~/.npm-global/bin کو PATH پر ~/.bashrc سے export کریں، interactive guard کے اوپر۔ اگر آپ نے پہلے ہی sudo npm ایک بار چلا لیا ہے، تو کیش کو sudo chown -R $(id -u):$(id -g) ~/.npm سے درست کریں۔

کیا ssh -A agent forwarding ایک ایسے سرور پر محفوظ ہے جہاں کوئی agent چل رہا ہے؟

یہ کام کی ضرورت سے کہیں زیادہ رسائی دیتا ہے۔ Forwarding آپ کے مقامی SSH agent کے socket کو اس user کے طور پر چلنے والے ہر پروسیس کو بے نقاب کرتا ہے، اس لیے سرور پر کوئی بھی چیز آپ کی key سے کہہ سکتی ہے کہ وہ جتنے hosts تک پہنچ سکتی ہے ان سب کے لیے سائن کرے، جب تک آپ منسلک رہتے ہیں۔ سرور پر ایک ed25519 key بنائیں اور اسے ہر ریپوزٹری کے لیے ایک deploy key کے طور پر رجسٹر کریں، اور write access صرف اس صورت میں دیں اگر agent کو واقعی push کرنا ہو۔

میری build صرف Killed کیوں پرنٹ کرتی ہے؟

کوئی 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 کو چن سکتا ہے، جس سے آپ کی پوری سیشن ختم ہو سکتی ہے۔

tmux یا systemd service؟

tmux ان interactive سیشنز کے لیے موزوں ہے جن سے آپ منسلک ہوتے ہیں، دیکھتے ہیں اور ان میں ٹائپ کرتے ہیں، جو کہ ایک ایجنٹ سیشن بالکل ہوتا ہے۔ وہ کام جو کسی شیڈول پر بغیر کسی دیکھنے والے کے چلتا ہے، وہ ایک systemd unit اور timer میں رکھنے کے قابل ہے، جہاں logging، restart policy اور boot survival مفت میں مل جاتی ہیں۔ اگر آپ cron نما job چلانے کے لیے tmux کی طرف رجوع کر رہے ہیں، تو اس job کو ایک service بننا چاہیے۔