Headless VPS-এ Gemini CLI চালানোর সম্পূর্ণ গাইড

আপনি যা তৈরি করছেন

আপনার নিজস্ব সার্ভারে চালানো একটি সবসময়-সক্রিয় Gemini CLI, যা SSH-এর মাধ্যমে ব্যবহারযোগ্য এবং দীর্ঘ agent task চালাতে পারে। ল্যাপটপ বন্ধ করলেও task চলতে থাকবে। ইনস্টল করতে তিনটি command লাগে। আসল কাজ হয় desktop ধরে নেওয়া অংশগুলো সামলাতে। Google-এর CLI লগ ইন করার জন্য browser খুলতে চায়, কিন্তু আপনার সার্ভারে browser নেই। তাই এই গাইডের বেশিরভাগ অংশে headless পদ্ধতি, distro যে বর্তমান Node দেবে না সেটি ইনস্টল করা, root ছাড়া global npm install করা, shell history-তে না রেখে API key দিয়ে browser ছাড়া authentication করা এবং tmux ব্যবহার করা দেখানো হয়েছে। এতে SSH session বিচ্ছিন্ন হলেও চলমান task বন্ধ হয় না।

Gemini CLI একটি open-source (Apache-2.0) Node program (@google/gemini-cli), যা Google-এর Gemini model-এর সঙ্গে যোগাযোগ করতে পারে, working directory-তে file পড়তে ও লিখতে পারে, shell command চালাতে পারে এবং tool ব্যবহার করতে পারে। VPS-এ এটি একটি ছোট, সবসময়-উপলভ্য agent হিসেবে কাজ করে, যাকে চলমান রেখে দেওয়া যায়। তাই এটি যে account হিসেবে চলে এবং সার্ভারে থাকা credentials-এর নিরাপত্তা এখানে যেকোনো একক setting-এর চেয়ে বেশি গুরুত্বপূর্ণ।

পূর্বশর্ত এবং গুরুত্বপূর্ণ সীমাবদ্ধতা

• root বা sudo-সহ একটি নতুন Ubuntu 24.04 KVM VPS। যেকোনো KVM plan কাজ করবে; CLI নিজে হালকা, idle অবস্থায় কয়েকশ MB RAM ব্যবহার করে।
• Node.js 20 বা তার পরের সংস্করণ। এটিই একমাত্র কঠোর version requirement, আর distro package-এ এর চেয়ে পুরোনো সংস্করণ থাকে; পরের section দেখুন।
• Google's APIs-এ outbound HTTPS (port 443)। কোনো inbound port প্রয়োজন নেই; এটি server নয়, client। তাই এর জন্য firewall-এ কোনো inbound rule খুলতে হবে না।
• এমন authentication পদ্ধতি, যার জন্য server-এ browser দরকার হয় না: Google AI Studio থেকে নেওয়া Gemini API key, অথবা নিজের machine-এর browser-এ ফিরে যাওয়ার জন্য একটি SSH tunnel। API-key পদ্ধতিই script এবং unattended run-এর জন্য উপযোগী।
• Docker বা Podman, শুধু যদি --sandbox isolation চান। এটি optional এবং শেষের দিকে আলোচনা করা হয়েছে।

যে সীমাবদ্ধতায় প্রায় সবাই সমস্যায় পড়ে: সহজ gemini first-run login flow-টি desktop-এর জন্য তৈরি। এটি browser খোলার চেষ্টা করে এবং headless box-এ হয় ব্যর্থ হয়, নয়তো এমন একটি link দেয় যা কাজ করে না। শুরু করার আগে authentication পদ্ধতি নির্ধারণ করুন।

Node: distro package-টি খুব পুরোনো

Ubuntu 24.04-এর নিজস্ব repository-তে npm 9.2.0-এর সঙ্গে Node 18.19.1 দেওয়া হয়। Gemini CLI-এর package.json-এ engines: { node: ">=20" } ঘোষণা করা আছে। npm ডিফল্টভাবে version mismatch-এ installation বন্ধ করে না। এটি package install করে এবং যে gap আছে তা উল্লেখ করে একটি warning দেখায়:

npm WARN EBADENGINE Unsupported engine {
npm WARN EBADENGINE   package: '@google/gemini-cli@0.50.0',
npm WARN EBADENGINE   required: { node: '>=20' },
npm WARN EBADENGINE   current: { node: 'v18.19.1', npm: '9.2.0' }
npm WARN EBADENGINE }

এই warning উপেক্ষা করে এগোলে CLI unsupported runtime-এ চলে। Node 20+ API-তে পৌঁছানোর সঙ্গে সঙ্গে, যেটি থাকার কথা ধরে নেওয়া হয়েছে, এটি ভুলভাবে কাজ করতে পারে বা crash করতে পারে। Node 18-এর support-ও April 2025-এ শেষ হয়েছে। তাই যেকোনো দিক থেকেই এটি ব্যবহারযোগ্য নয়। CLI install করার আগে একটি current LTS install করুন। এর দুটি নির্ভরযোগ্য পদ্ধতি হলো NodeSource (system-wide signed apt repo) অথবা nvm (per-user version manager)। যেকোনো একটি বেছে নিন।

যদি এই host-এর সব user-এর জন্য Node উপলভ্য রাখতে চান, তাহলে NodeSource ব্যবহার করুন:

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

node --version-এ v20.x বা তার বেশি দেখাতে হবে। v24.x বর্তমানে active LTS। বর্তমান setup script-এর জন্য NodeSource-এর page দেখুন। URL-এর setup_24.x অংশটি হলো নতুন LTS প্রকাশিত হলে যে version পরিবর্তন করতে হবে।

যদি Node-কে একজন user-এর home directory-র মধ্যে রাখতে চান এবং কখনও sudo দিয়ে সেটি পরিচালনা করতে না চান, তাহলে nvm ব্যবহার করুন:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
source ~/.bashrc
nvm install --lts
node --version

এই লেখা তৈরির সময় URL-এর v0.40.1 সর্বশেষ ছিল। চালানোর আগে nvm-এর README-তে latest release দেখুন এবং সেখানে version পরিবর্তন করুন। এই কাজের জন্য nvm-এর একটি গুরুত্বপূর্ণ সুবিধা আছে: এটি Node এবং তার global package-গুলো ~/.nvm-এর অধীনে install করে। ফলে পরের section-এ বর্ণিত global-install permission সমস্যা হয় না। nvm ব্যবহার করলে npm-prefix ধাপটি বাদ দিতে পারেন।

Install the CLI without sudo npm -g

The tempting command is sudo npm install -g @google/gemini-cli. Do not. A root-owned global prefix produces permission errors on every later install and leaves root-owned files in your npm cache that bite months from now. Run a plain (no-sudo) npm install -g against a system Node and you get the other failure:

npm error code EACCES
npm error syscall mkdir
npm error path /usr/lib/node_modules/@google
npm error errno -13
npm error Error: EACCES: permission denied, mkdir '/usr/lib/node_modules/@google'

That is npm trying to write into /usr/lib, which your user cannot. The fix is not sudo, it is to point npm's global prefix at your home directory so global installs land somewhere you own:

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

~/.bashrc, not ~/.profile, is deliberate: tmux, which you will run the CLI inside two sections from now, starts a non-login shell that reads ~/.bashrc and skips ~/.profile, so a PATH line in the wrong file leaves gemini invisible in exactly the place you need it. gemini --version printing a version number is the whole test. If you instead get gemini: command not found, your PATH export did not take, see the failure modes. On nvm, skip the prefix lines entirely: it already installs globals under your home.

If you ran sudo npm at some earlier point and now see Your cache folder contains root-owned files, repair it once with sudo chown -R $(id -u):$(id -g) ~/.npm.

হেডলেস authentication সমস্যা এবং এটি সমাধানের উপায়

প্রথমবার gemini ইন্টার‌্যাক্টিভভাবে চালালে এটি আপনার Google account দিয়ে লগ ইন করার প্রস্তাব দেয়। Desktop-এ এটি একটি browser tab খোলে। Headless VPS-এ কোনো browser থাকে না। তাই এই প্রক্রিয়া হয় এমন একটি localhost URL দেখায়, যা আপনাকে খুলতে বলে, অথবা সরাসরি নিচের মতো কোনো ত্রুটিতে ব্যর্থ হয়:

Failed to open browser. Please visit the following URL to authorize:
https://accounts.google.com/o/oauth2/v2/auth?...&redirect_uri=http://localhost:PORT

সমস্যাটি হলো redirect_uri=http://localhost:PORT। আপনি laptop-এ সেই URL খুলে অনুমোদন করলেও Google আপনাকে http://localhost:PORT-এ redirect করে। এটি server-এর localhost, তাই laptop থেকে ওই port-এ পৌঁছানো যায় না। ফলে login সম্পূর্ণ হয় না।

এটি সমাধানের দুটি নির্ভরযোগ্য উপায় আছে।

প্রথম উপায় হলো API key ব্যবহার করা। Server-এর জন্য এটিই সাধারণত সঠিক পদ্ধতি। Google AI Studio (aistudio.google.com)-এ একটি key তৈরি করুন এবং environment variable হিসেবে CLI-কে দিন। এটি GEMINI_API_KEY পড়ে এবং browser flow সম্পূর্ণ এড়িয়ে যায়। এখন key-টি history এবং অন্যদের পড়ার উপযোগী file থেকে কীভাবে নিরাপদে রাখবেন, সেটি দেখুন। Prompt-এ export GEMINI_API_KEY=AIza... টাইপ করবেন না। এতে key-টি ~/.bash_history-এ cleartext হিসেবে সংরক্ষিত হবে। এমন কোনো file-এও এটি রাখবেন না, যা অন্যরা পড়তে পারে। Shell start হওয়ার সময় source করে এমন mode-600 file-এ এটি লিখুন:

umask 077
printf 'export GEMINI_API_KEY=%s\n' 'AIzaSyYOUR_KEY_HERE' > ~/.gemini_env
chmod 600 ~/.gemini_env
echo '[ -f ~/.gemini_env ] && . ~/.gemini_env' >> ~/.bashrc
source ~/.bashrc

chmod 600-এর অর্থ হলো শুধু আপনার user file-টি পড়তে পারবে। printenv GEMINI_API_KEY দিয়ে key environment-এ পৌঁছেছে কি না নিশ্চিত করুন। এটি কিছু না দেখালে CLI browser flow-এ ফিরে যাবে এবং ব্যর্থ হবে। আপনি চাইলে ~/.gemini/-এ থাকা .env file-ও ব্যবহার করতে পারেন। সেখানেও একই নিয়ম প্রযোজ্য, অর্থাৎ chmod 600 ~/.gemini/.env।

দ্বিতীয় উপায়ে personal Google account login এবং এর free tier ব্যবহার করা যায়। এ ক্ষেত্রে OAuth callback-টি tunnel করে আপনার laptop-এ ফেরত পাঠাতে হবে। সমস্যা হলো, CLI প্রতিবার loopback server-এর জন্য একটি random port ব্যবহার করে। তাই আগে OAUTH_CALLBACK_PORT environment variable দিয়ে port নির্দিষ্ট না করলে forward করার মতো স্থায়ী port থাকে না। এরপর ঠিক সেই port forward করুন:

# from your laptop, forward the callback port into the SSH session:
ssh -L 8085:localhost:8085 user@your-server
# then, on the server, pin the callback to the same port and start the CLI:
export OAUTH_CALLBACK_PORT=8085
gemini

CLI browser খুলতে পারে না। তাই এটি auth URL দেখাবে। Laptop-এর browser-এ URL-টি খুলে অনুমোদন করুন। Google যখন http://localhost:8085/...-এ redirect করবে, তখন SSH forward সেই request-টি VPS-এর loopback server-এ পৌঁছে দেবে এবং login সম্পূর্ণ হবে। Port নির্দিষ্ট না করলে প্রতিবার নতুন random port ব্যবহৃত হবে। ফলে আগে থেকে তৈরি কোনো ssh -L সেই request ধরতে পারবে না। পদ্ধতিটি কাজ করে, তবে browser-এর সামনে আপনাকে উপস্থিত থাকতে হয়। তাই script-এর জন্য এটি উপযুক্ত নয়। দীর্ঘ সময় চালু রাখা যেকোনো service-এর জন্য API key ব্যবহার করুন।

AI Studio-এর পরিবর্তে Vertex AI বা Google Cloud project ব্যবহার করতে GOOGLE_API_KEY-এর সঙ্গে GOOGLE_GENAI_USE_VERTEXAI=true সেট করুন। Code Assist licence-এর জন্য GOOGLE_CLOUD_PROJECT ব্যবহার করুন। একই environment-variable নিরাপত্তা নিয়ম এবং একই mode-600 file প্রযোজ্য।

tmux-এর ভিতরে চালান, যাতে SSH সংযোগ বিচ্ছিন্ন হলেও এটি বন্ধ না হয়

আপনার SSH shell থেকে সরাসরি চালু করা একটি gemini process ওই shell-এর child। সংযোগ বিচ্ছিন্ন হওয়া, ল্যাপটপ বন্ধ হয়ে যাওয়া, Wi-Fi কেটে যাওয়া বা idle timeout ঘটলে sshd pseudo-terminal বন্ধ করে দেয়, shell SIGHUP পায় এবং এরপর CLI-কে বন্ধ করে দেয়। ফাইল সম্পাদনার 10 মিনিট পরেও কোনো task এর সঙ্গে বন্ধ হয়ে যায়। পুনরায় সংযোগ করলে পুনরুদ্ধার করার মতো কোনো process থাকে না।

tmux এই সমস্যা সমাধান করে, কারণ এটি shell-কে নিজের অধীনে রাখে; sshd shell-কে নিজের অধীনে রাখে না। এটি tmux-এর ভিতরে remote VPS-এ AI coding agent চালানোর একই পদ্ধতি এবং এখানেও একইভাবে কাজ করে:

sudo apt install -y tmux
tmux new -A -s gemini
# inside the session:
gemini
# detach with Ctrl-b then d — the task keeps running
# reconnect later from any machine:
tmux attach -t gemini

tmux new -A -s gemini থাকলে gemini নামের session-এ সংযুক্ত হয় এবং না থাকলে সেটি তৈরি করে। তাই প্রতিবার login-এর পর চালানোর জন্য এটিই একমাত্র command। এর ভিতরের shell detached tmux server-এর অধীনে থাকে, আপনার SSH session-এর অধীনে নয়। ফলে সংযোগ বিচ্ছিন্ন হলেও CLI কাজ করতে থাকে। আবার সংযোগ করুন, attach করুন, এবং একই scrollback-এ ফিরে আসুন। একই server-এ একাধিক agent session চালালে প্রতিটির জন্য আলাদা tmux session ব্যবহার করুন। এখানে তারা একে অপরের সঙ্গে যোগাযোগ করতে পারে না। এটি Claude Code-এর বিপরীত, যেখানে একই VPS-এ একটি session অন্য session-এ text পাঠাতে পারে। তাই প্রতিটি Gemini job আলাদা রাখুন, অথবা disk-এ থাকা file-এর মাধ্যমে তাদের সমন্বয় করুন।

Non-interactive, scripted run-এর জন্য Gemini CLI-এর headless mode আছে: gemini -p "summarise the failing tests in this repo" একটি answer print করে এবং exit করে, আর --output-format json অন্যত্র pipe করার জন্য machine-readable output দেয়। API key-সহ headless mode দীর্ঘ batch job চালানো tmux session-এর ভিতরে বা cron entry থেকে চালানোর জন্য উপযুক্ত। তবে একটি বিষয় মনে রাখুন: cron job আপনার কোনো login file source করে না। তাই crontab line-এ নিজস্ব GEMINI_API_KEY দিন, অথবা command-কে ~/.gemini_env source করান। তা না হলে CLI browser flow-তে fallback করবে এবং ব্যর্থ হবে।

একই production চালানো সার্ভারে sandboxing ও permission

Shell access থাকা কোনো agent কার্যত একটি shell। Gemini CLI command চালাতে পারে। ডিফল্টভাবে এটি প্রতিটি ঝুঁকিপূর্ণ command-এর আগে অনুমতি চায়। তবে অনেকে --yolo ব্যবহার করেন, যা প্রতিটি tool call স্বয়ংক্রিয়ভাবে অনুমোদন করে। তখন agent-টি যে user account দিয়ে চলছে, তার সম্পূর্ণ authority ব্যবহার করে file delete করতে, git-এ push করতে বা internal service-এ request পাঠাতে পারে। একই সার্ভারে production workload চললে এর প্রভাবের পরিধি বাস্তব, অনুমাননির্ভর নয়।

নিচের 3টি control ব্যবহার করুন। এগুলো কতটা সুরক্ষা দেয়, সেই ক্রমে সাজানো হয়েছে:

• এটি একটি dedicated, unprivileged user হিসেবে চালান। root হিসেবে নয় এবং sudo-এর member হিসেবেও নয়। নিজস্ব home সহ একটি agent user তৈরি করুন। সেখানে Node ও CLI install করুন। কোনো instruction ভুলভাবে বোঝা হলেও তার প্রভাব ওই account-এর মধ্যেই সীমিত থাকবে। এটিই সবচেয়ে বেশি নিরাপত্তা দেওয়া একক সিদ্ধান্ত।
• Production credential সার্ভারে রাখবেন না। কোনো prod ~/.aws/credentials রাখবেন না। Production থেকে কোনো .env copy করে আনবেন না। গুরুত্বপূর্ণ কোনো resource-এ write access থাকা database password-ও দেবেন না। এর পরিবর্তে staging credential বা read-only credential দিন।
• Built-in sandbox ব্যবহার করুন। Docker বা Podman install করা থাকলে gemini --sandbox অথবা GEMINI_SANDBOX=docker agent-এর tool call-গুলো host filesystem ও network থেকে বিচ্ছিন্ন একটি container-এর ভিতরে চালায়। এটি unprivileged user-এর বিকল্প নয়। তবে একই VPS-এ production workload চললে এটি একটি শক্তিশালী দ্বিতীয় নিরাপত্তা স্তর।

আপনি যদি অন্য self-hosted tooling-এর পাশাপাশি Gemini CLI চালান, যেমন একই VPS-এ agent-এর জন্য tool expose করা একটি MCP server, তাহলে প্রতিটি অতিরিক্ত capability-কে agent-এর কাছে পৌঁছাতে পারে এমন নতুন attack surface হিসেবে বিবেচনা করুন। Agent-কে দেওয়া token-এর scope ঠিক একটি কাজের মধ্যে সীমাবদ্ধ রাখুন।

Quota, খরচ এবং আপনি কোন auth path বেছে নিয়েছেন

auth path নির্ধারণ করে আপনাকে কীভাবে বিল করা হবে। একটি personal Google account (OAuth path) বিনামূল্যের Gemini Code Assist tier ব্যবহার করে, যেখানে প্রতি মিনিট ও প্রতি দিনের বাস্তব সীমা থাকে; এই সীমা অতিক্রম করলে window reset না হওয়া পর্যন্ত request rate-limit error ফেরত দেয়। AI Studio-এর একটি API key free tier-এ থাকতে পারে অথবা project অনুযায়ী billed হতে পারে। billed key সীমা বাড়ায় এবং প্রতি token অনুযায়ী খরচ নেয়। Vertex ও Cloud-project auth-এর বিল Google Cloud-এর মাধ্যমে হয়।

দুটি ব্যবহারিক বিষয় মনে রাখুন। Loop-এর মধ্যে unattended agent দ্রুত quota শেষ করতে পারে। তাই cron job-এ চালানোর আগে প্রথম কয়েকবার এটি monitor করুন। আর server-side model ব্যবহারের কারণ যদি privacy বা Google-এর hosted model-এর পরিবর্তে unmetered inference হয়, তাহলে সেটি ভিন্ন tool। VPS-এ Ollama দিয়ে open LLM self-hosting করলে weights এবং prompts আপনার নিজের box-এ থাকে। এর বিনিময়ে Gemini-এর তুলনায় অনেক ছোট model চালাতে হয়।

আপডেট রাখা

Gemini CLI নিয়মিত নতুন release প্রকাশ করে। এটি আপনার ব্যবহারকারীর মালিকানাধীন prefix-এ ইনস্টল করায় আপডেটের জন্য কখনো sudo প্রয়োজন হয় না:

npm install -g @google/gemini-cli@latest
gemini --version

Release channel রয়েছে: @latest হলো stable, @preview হলো সাপ্তাহিক preview, আর @nightly হলো bleeding edge। যেসব কিছুর ওপর আপনি নির্ভর করেন, সেগুলোর জন্য @latest-এ স্থির থাকুন। nvm-এ global package সক্রিয় Node version-এর অধীনে থাকে। তাই Node পরিবর্তনের জন্য nvm use করার পরে CLI আবার ইনস্টল করতে হতে পারে। প্রতিটি patch অনুসরণ না করে release notes পড়ুন।

ব্যর্থতার ধরন, সঠিক স্ট্রিংসহ

npm WARN EBADENGINE Unsupported engine ... required: { node: '>=20' }, এরপর runtime-এ CLI crash করা। Node-এর সংস্করণ খুব পুরোনো; distro-তে থাকা 18.19.1 সংস্করণটির end-of-life-ও পেরিয়ে গেছে। NodeSource বা nvm থেকে Node 20+ ইনস্টল করুন। node --version দিয়ে যাচাই করুন। একাধিক Node ইনস্টল করা থাকলে which node নতুন সংস্করণটির দিকে নির্দেশ করছে কি না দেখুন, /usr/bin/node-এর দিকে নয়।

npm error code EACCES / permission denied, mkdir '/usr/lib/node_modules/...'। root-owned prefix-এ global install করা হয়েছে। sudo ব্যবহার করবেন না। npm config set prefix ~/.npm-global সেট করুন, ~/.npm-global/bin-কে PATH-এ যোগ করুন, এবং আপনার সাধারণ user হিসেবে পুনরায় install করুন। আগের sudo npm root-owned cache file রেখে গেলে (Your cache folder contains root-owned files), sudo chown -R $(id -u):$(id -g) ~/.npm চালান।

Failed to open browser, এমন login যা আটকে থাকে, অথবা এমন redirect_uri=http://localhost:PORT-এ পৌঁছানো যায় না। OAuth flow এমন একটি browser চায়, যা সার্ভারে নেই। এর localhost callback আপনার laptop-এর বদলে সার্ভারের দিকে নির্দেশ করে। API-key path (GEMINI_API_KEY) ব্যবহার করুন। অথবা OAUTH_CALLBACK_PORT নির্দিষ্ট করুন, ssh -L দিয়ে SSH-এর মাধ্যমে forward করুন, এবং URL-টি locally খুলুন।

SSH বিচ্ছিন্ন হলে process অদৃশ্য হয়ে গেছে। আপনি SSH shell থেকেই সরাসরি gemini চালিয়েছিলেন। তাই এটি ওই shell-এর child process ছিল এবং disconnect হলে pty-এর সঙ্গে বন্ধ হয়ে গেছে। পুনরুদ্ধার করার মতো কিছু নেই। প্রতিটি session tmux new -A -s gemini দিয়ে শুরু করুন এবং CLI সেটির ভেতরে চালান।

Key সেট করা থাকা সত্ত্বেও auth ব্যর্থ হয়, CLI আবার auth picker-এ ফিরে যায়, অথবা কোনো request HTTP 400 সহ API key not valid ফেরত দেয়। CLI যে environment দেখতে পাচ্ছে, সেখানে key নেই। printenv GEMINI_API_KEY দিয়ে নিশ্চিত করুন। এটি খালি হলে আপনার ~/.gemini_env কখনো source করা হয়নি। পরীক্ষা করুন লাইনটি ~/.bashrc-এ আছে কি না। Interactive shell (tmux-সহ) এটি পড়ে, কিন্তু cron এবং অন্যান্য non-interactive shell পড়ে না। Key value-এর ভেতরে অতিরিক্ত space বা quote থাকলেও API key not valid তৈরি হয়।

429 / RESOURCE_EXHAUSTED / rate-limit message। আপনার auth যে tier ব্যবহার করছে, তার quota শেষ হয়ে গেছে। Window reset হওয়া পর্যন্ত অপেক্ষা করুন, agent-এর গতি কমান, অথবা billed API key ব্যবহার করুন। কোনো agent retry loop-এ আটকে থাকলে সে বারবার এই সীমায় পৌঁছাবে। Agent-টি থামিয়ে কী করছে তা পরীক্ষা করুন।

FAQ

Gemini CLI-কে headless server-এ কীভাবে authenticate করব?

Browser login নয়, API key ব্যবহার করুন। Google AI Studio-তে একটি key তৈরি করে সেটি আপনার shell যে mode-600 ফাইল source করে (export GEMINI_API_KEY=...), সেখানে রাখুন। এতে CLI সম্পূর্ণভাবে OAuth browser flow এড়িয়ে যাবে। আপনি যদি বিশেষভাবে personal-account free tier ব্যবহার করতে চান, তাহলে OAUTH_CALLBACK_PORT=8085 দিয়ে loopback port নির্দিষ্ট করুন, ssh -L 8085:localhost:8085 user@server দিয়ে সেটি আপনার laptop-এ forward করুন, এবং localভাবে প্রদর্শিত URL খুলুন। তবে এর জন্য browser-এর সামনে আপনার উপস্থিত থাকা দরকার। তাই script-এর জন্য এটি উপযুক্ত নয়।

npm global install sudo চাইছে কেন, এবং কীভাবে তা এড়াব?

কারণ npm-এর default global prefix হলো /usr/lib/node_modules, যেখানে আপনার user লিখতে পারে না। তাই সাধারণ npm install -g, EACCES-সহ ব্যর্থ হয়। ভুল সমাধান হলো sudo npm -g ব্যবহার করা। এতে root-owned file তৈরি হয়, যা পরবর্তী install ব্যর্থ করে। সঠিক সমাধান হলো prefix-কে আপনার home directory-তে (npm config set prefix ~/.npm-global) নির্দিষ্ট করা এবং তার bin-কে PATH-এ যোগ করা। অথবা nvm ব্যবহার করুন। nvm স্বয়ংক্রিয়ভাবে আপনার home directory-র অধীনে global package install করে।

Disconnect করার পর Gemini CLI চালু রাখব কীভাবে?

এটি tmux-এর ভিতরে চালান। আপনার SSH shell থেকে শুরু করা process connection বিচ্ছিন্ন হলে বন্ধ হয়ে যায়, কারণ এটি ওই shell-এর child process। tmux একটি detached server-এর অধীনে shell চালায়, যা disconnect হলেও চালু থাকে। tmux new -A -s gemini ব্যবহার করুন, তার ভিতরে gemini চালান, Ctrl-b d দিয়ে detach করুন, এবং পরে tmux attach -t gemini দিয়ে আবার সংযুক্ত হন।

Production box-এ Gemini CLI চালানো কি নিরাপদ?

শুধু সতর্কতার সঙ্গে চালানো নিরাপদ। কারণ shell access-সহ কোনো agent তার user যতটুকু করতে পারে, ততটুকুই করতে পারে। এটিকে sudo ছাড়া একটি নির্দিষ্ট unprivileged user হিসেবে চালান। Production credential মেশিনে রাখবেন না। --yolo auto-approval এড়িয়ে চলুন। Tool call-গুলোকে host system থেকে আলাদা রাখতে --sandbox (Docker বা Podman) ব্যবহার করুন। আপনি কোন একক flag সেট করেছেন তার চেয়ে agent যে account-এর অধীনে চলে, সেটি বেশি গুরুত্বপূর্ণ।

Gemini CLI-এর জন্য কি কোনো firewall port খুলতে হবে?

না। এটি একটি client, যা Google-এর API-তে outbound HTTPS call করে। তাই outbound port 443 প্রয়োজন, কিন্তু কোনো inbound port প্রয়োজন হয় না। OAuth tunnel ব্যবহার করলে pinned callback port (যেমন 8085) localhost-এ থাকে এবং আপনার SSH forward-এর মাধ্যমে পৌঁছানো যায়। এটি কোনো খোলা inbound port নয়। Inbound traffic সীমিত রাখুন।