# Remote Mode (မြန်မာ) 🌐 **Languages:** 🇺🇸 [English](../../../../guides/REMOTE-MODE.md) · 🇪🇹 [am](../../../am/docs/guides/REMOTE-MODE.md) · 🇸🇦 [ar](../../../ar/docs/guides/REMOTE-MODE.md) · 🇦🇿 [az](../../../az/docs/guides/REMOTE-MODE.md) · 🇧🇬 [bg](../../../bg/docs/guides/REMOTE-MODE.md) · 🇧🇩 [bn](../../../bn/docs/guides/REMOTE-MODE.md) · 🇧🇦 [bs](../../../bs/docs/guides/REMOTE-MODE.md) · 🇨🇿 [cs](../../../cs/docs/guides/REMOTE-MODE.md) · 🇩🇰 [da](../../../da/docs/guides/REMOTE-MODE.md) · 🇩🇪 [de](../../../de/docs/guides/REMOTE-MODE.md) · 🇬🇷 [el](../../../el/docs/guides/REMOTE-MODE.md) · 🇪🇸 [es](../../../es/docs/guides/REMOTE-MODE.md) · 🇪🇪 [et](../../../et/docs/guides/REMOTE-MODE.md) · 🇮🇷 [fa](../../../fa/docs/guides/REMOTE-MODE.md) · 🇫🇮 [fi](../../../fi/docs/guides/REMOTE-MODE.md) · 🇫🇷 [fr](../../../fr/docs/guides/REMOTE-MODE.md) · 🇮🇪 [ga](../../../ga/docs/guides/REMOTE-MODE.md) · 🇮🇳 [gu](../../../gu/docs/guides/REMOTE-MODE.md) · 🇳🇬 [ha](../../../ha/docs/guides/REMOTE-MODE.md) · 🇮🇱 [he](../../../he/docs/guides/REMOTE-MODE.md) · 🇮🇳 [hi](../../../hi/docs/guides/REMOTE-MODE.md) · 🇭🇷 [hr](../../../hr/docs/guides/REMOTE-MODE.md) · 🇭🇺 [hu](../../../hu/docs/guides/REMOTE-MODE.md) · 🇦🇲 [hy](../../../hy/docs/guides/REMOTE-MODE.md) · 🇮🇩 [id](../../../id/docs/guides/REMOTE-MODE.md) · 🇳🇬 [ig](../../../ig/docs/guides/REMOTE-MODE.md) · 🇮🇹 [it](../../../it/docs/guides/REMOTE-MODE.md) · 🇯🇵 [ja](../../../ja/docs/guides/REMOTE-MODE.md) · 🇬🇪 [ka](../../../ka/docs/guides/REMOTE-MODE.md) · 🇰🇭 [km](../../../km/docs/guides/REMOTE-MODE.md) · 🇮🇳 [kn](../../../kn/docs/guides/REMOTE-MODE.md) · 🇰🇷 [ko](../../../ko/docs/guides/REMOTE-MODE.md) · 🇱🇹 [lt](../../../lt/docs/guides/REMOTE-MODE.md) · 🇱🇻 [lv](../../../lv/docs/guides/REMOTE-MODE.md) · 🇮🇳 [ml](../../../ml/docs/guides/REMOTE-MODE.md) · 🇮🇳 [mr](../../../mr/docs/guides/REMOTE-MODE.md) · 🇲🇾 [ms](../../../ms/docs/guides/REMOTE-MODE.md) · 🇲🇹 [mt](../../../mt/docs/guides/REMOTE-MODE.md) · 🇳🇵 [ne](../../../ne/docs/guides/REMOTE-MODE.md) · 🇳🇱 [nl](../../../nl/docs/guides/REMOTE-MODE.md) · 🇳🇴 [no](../../../no/docs/guides/REMOTE-MODE.md) · 🇮🇳 [or](../../../or/docs/guides/REMOTE-MODE.md) · 🇮🇳 [pa](../../../pa/docs/guides/REMOTE-MODE.md) · 🇵🇭 [phi](../../../phi/docs/guides/REMOTE-MODE.md) · 🇵🇱 [pl](../../../pl/docs/guides/REMOTE-MODE.md) · 🇵🇹 [pt](../../../pt/docs/guides/REMOTE-MODE.md) · 🇧🇷 [pt-BR](../../../pt-BR/docs/guides/REMOTE-MODE.md) · 🇷🇴 [ro](../../../ro/docs/guides/REMOTE-MODE.md) · 🇷🇺 [ru](../../../ru/docs/guides/REMOTE-MODE.md) · 🇱🇰 [si](../../../si/docs/guides/REMOTE-MODE.md) · 🇸🇰 [sk](../../../sk/docs/guides/REMOTE-MODE.md) · 🇸🇮 [sl](../../../sl/docs/guides/REMOTE-MODE.md) · 🇷🇸 [sr](../../../sr/docs/guides/REMOTE-MODE.md) · 🇸🇪 [sv](../../../sv/docs/guides/REMOTE-MODE.md) · 🇰🇪 [sw](../../../sw/docs/guides/REMOTE-MODE.md) · 🇮🇳 [ta](../../../ta/docs/guides/REMOTE-MODE.md) · 🇮🇳 [te](../../../te/docs/guides/REMOTE-MODE.md) · 🇹🇭 [th](../../../th/docs/guides/REMOTE-MODE.md) · 🇹🇷 [tr](../../../tr/docs/guides/REMOTE-MODE.md) · 🇺🇦 [uk-UA](../../../uk-UA/docs/guides/REMOTE-MODE.md) · 🇵🇰 [ur](../../../ur/docs/guides/REMOTE-MODE.md) · 🇺🇿 [uz](../../../uz/docs/guides/REMOTE-MODE.md) · 🇻🇳 [vi](../../../vi/docs/guides/REMOTE-MODE.md) · 🇳🇬 [yo](../../../yo/docs/guides/REMOTE-MODE.md) · 🇨🇳 [zh-CN](../../../zh-CN/docs/guides/REMOTE-MODE.md) · 🇹🇼 [zh-TW](../../../zh-TW/docs/guides/REMOTE-MODE.md) --- OmniRoute ကို အခြားတစ်နေရာတွင် (VPS၊ အိမ်သုံးဆာဗာ သို့မဟုတ် သင့် Tailnet ပေါ်ရှိ အခြားစက်တစ်လုံးတွင်) အသုံးပြုနေစဉ် သင့်လက်ပ်တော့ပေါ်၌ `omniroute` CLI ကို အသုံးပြုနိုင်သည်။ `omniroute connect` ဖြင့် တစ်ကြိမ် အကောင့်ဝင်ပြီးနောက် **CLI command အားလုံး** သည် ထိုအဝေးထိန်းဆာဗာကို ဦးတည်မည်ဖြစ်သည် — command များနှင့် output များသည် အတူတူပင်ဖြစ်ပြီး အဝေးထိန်းဆာဗာပေါ်တွင်သာ လုပ်ဆောင်ပါသည်။ ဒုတိယ tool တစ်ခု ထပ်မံထည့်သွင်းရန် မလိုပါ။ remote mode သည် ပုံမှန် `omniroute` CLI နှင့် scope သတ်မှတ်ထားသော **access token များ** ကို အသုံးပြုပါသည်။ ```bash npm install -g omniroute # ပုံမှန် CLI omniroute connect 192.168.0.15 # အကောင့်ဝင်ခြင်း (စကားဝှက် → scope သတ်မှတ်ထားသော token) omniroute models list # ← ယခု အဝေးထိန်းဆာဗာ၏ model များကို စာရင်းပြမည် omniroute configure codex # ← အဝေးထိန်း catalog မှ local Codex profile တစ်ခုကို ရေးမည် ``` --- ## အလုပ်လုပ်ပုံ ``` သင့်လက်ပ်တော့ အဝေးထိန်း OmniRoute (VPS) ┌────────────────────┐ ┌───────────────────────────────┐ │ omniroute CLI │ POST /api/cli/connect (စကားဝှက် → token) │ │ context: vps │ ───────────────► │ scope သတ်မှတ်ထားသော access token ထုတ်ပေးသည် │ │ baseUrl, token │ Authorization: Bearer oma_live_… │ │ │ ───────────────► │ management route တစ်ခုစီကို token ၏ scope │ │ config များကို │ ◄─────────────── │ အလိုက် စစ်ဆေးသည် │ │ LOCAL တွင် ရေးသည် │ └───────────────────────────────┘ └────────────────────┘ ``` - **Context များ** သည် ဆာဗာတစ်ခုစီကို သိမ်းဆည်းထားသည် (`~/.omniroute/config.json`, `chmod 600`)။ `omniroute contexts use ` သည် လက်ရှိအသုံးပြုနေသော ဆာဗာကို ပြောင်းပေးပြီး `default` သည် local ဖြစ်သည်။ - **Access token များ** (`oma_live_…`) သည် management command များကို ခွင့်ပြုပေးသည်။ ၎င်းတို့သည် inference API key များ (`sk-…`၊ `/v1/chat/completions` အတွက် အသုံးပြုသည်) နှင့် သီးခြားဖြစ်သည်။ - Token တစ်ခု၏ SHA-256 hash ကိုသာ server-side တွင် သိမ်းဆည်းထားသည်။ Plaintext ကို ဖန်တီးချိန်တွင် **တစ်ကြိမ်သာ** ပြသသည်။ --- ## ချိတ်ဆက်ခြင်း ### Management password ဖြင့် (bootstrap) ```bash omniroute connect 192.168.0.15 # http://192.168.0.15:20128 အတွက် management password: ******** # ✔ http://192.168.0.15:20128 သို့ ချိတ်ဆက်ပြီး — context '192.168.0.15' (scope: admin) ``` Password flow သည် မူလသတ်မှတ်ချက်အရ **admin** token တစ်ခုကို ထုတ်ပေးသည် (သင့်တွင် စကားဝှက်ရှိသောကြောင့် အပြည့်အဝထိန်းချုပ်ခွင့် ရှိပြီးသားဖြစ်သည်)။ `--scope` ဖြင့် scope ကို လျှော့ချနိုင်သည်။ ```bash omniroute connect 192.168.0.15 --scope write ``` ရွေးချယ်စရာများမှာ `--port

` (host တွင် port မပါရှိသည့်အခါ)၊ `--name ` (context အမည်) နှင့် `--scope read|write|admin` တို့ဖြစ်သည်။ URL အပြည့်အစုံကို ပေးထားသည့်အတိုင်း အသုံးပြုမည်ဖြစ်သည်။ `omniroute connect https://omni.example.com`။ ### ကြိုတင်ထုတ်ပေးထားသော token ဖြင့် Dashboard တွင် (သို့မဟုတ် `omniroute tokens create` ဖြင့်) scope သတ်မှတ်ထားသော token တစ်ခုကို ထုတ်ပေးပြီး ထည့်သွင်းပါ — စကားဝှက် မလိုအပ်ပါ။ ```bash omniroute connect 192.168.0.15 --key oma_live_xxxxxxxx ``` CLI သည် ၎င်းကို `GET /api/cli/whoami` မှတစ်ဆင့် စစ်ဆေးအတည်ပြုပြီး လက်ရှိ context အဖြစ် သိမ်းဆည်းသည်။ --- ## Scope များ အဆင့်သုံးဆင့်ရှိပြီး အထက်အောက်ဆင့်ဆင့် အကျုံးဝင်သည် (`admin ⊃ write ⊃ read`)။ | Scope | လုပ်ဆောင်နိုင်သည့်အရာများ | | ------- | ---------------------------------------------------------------------------------------- | | `read` | စာရင်းပြ/စစ်ဆေး — `models list`, `providers status`, `logs`, `usage`, `cost` | | `write` | read **+** ပြင်ဆင်သတ်မှတ်/အသုံးချ — `setup-codex`, `keys add`, `config set`, combo များ | | `admin` | write **+** စီမံခန့်ခွဲ — `tokens` CRUD၊ provider ထည့်ခြင်း၊ service များ၊ policy၊ oauth | ဆာဗာသည် route တစ်ခုစီအတွက် လိုအပ်သော scope ကို HTTP method မှ ခန့်မှန်းသတ်မှတ်သည် (`GET`→read၊ mutation များ→write)။ ထို့အပြင် အရေးကြီးသော surface များအတွက် admin allowlist ကိုလည်း အသုံးပြုသည် (`/api/cli/tokens`, `/api/providers` mutation များ၊ `/api/oauth`, `/api/services`, …)။ လုံလောက်သော scope မရှိသည့် token သည် ရှင်းလင်းသော message တစ်ခုနှင့်အတူ `403` ကို ရရှိမည်ဖြစ်သည်။ > Process များကို စတင်ပေးသည့် route များ (`/api/services/*`, `/api/mcp/*`, …) သည် > **loopback-only** အဖြစ်သာ ဆက်ရှိနေမည် — scope မည်သို့ပင်ဖြစ်စေ remote token ဖြင့် ၎င်းတို့ကို မည်သည့်အခါမျှ ဝင်ရောက်အသုံးပြု၍ မရပါ။ --- ## အဝေးမှ ထည့်သွင်းထားသောစနစ်တွင် Antigravity ချိတ်ဆက်ခြင်း Antigravity သည် Google ၏ firstparty/nativeapp သဘောတူညီချက်မျက်နှာပြင်ကို အသုံးပြုသည်။ **loopback redirect** (`http://127.0.0.1:/callback`) ကို **အကောင့်ဝင်ခြင်းအား အတည်ပြုသည့် browser မှ ဝင်ရောက်နိုင်မှသာ** Google က authorization code ကို ထုတ်ပေးသည်။ အဝေးရှိ VPS တွင် ထည့်သွင်းထားပါက ထို loopback သည် သင့်စက်ပေါ်တွင်မဟုတ်ဘဲ server ပေါ်တွင် ရှိသောကြောင့် သဘောတူညီချက်မျက်နှာပြင်သည် **အဆုံးမရှိ ရပ်ဆိုင်းနေပြီး code ကို လုံးဝ မထုတ်ပေးပါ** — ပုံမှန် "callback URL ကို paste လုပ်ပါ" အစားထိုးနည်းတွင် paste လုပ်စရာ ဘာမျှမရှိပါ။ (၎င်းသည် Google ဘက်မှ ကန့်သတ်ချက်ဖြစ်သည်။ OmniRoute သာမက ပူးတွဲပါ Antigravity desktop client ကို အသုံးပြုသည့် မည်သည့် proxy တွင်မဆို အလားတူ ရပ်ဆိုင်းမှု ဖြစ်ပေါ်သည်။) Dashboard သည် သင်ပိတ်မိမသွားမီ ယင်းအခြေအနေကို သိရှိနိုင်သည်။ localhost မဟုတ်သော လိပ်စာမှ **Providers → Antigravity → Connect** ကို ဖွင့်ပါက ယေဘုယျ "callback URL ကို ကူးယူပါ" အသိပေးချက်အစား အောက်ပါဖြေရှင်းနည်းနှစ်ခုကို သင့် host နှင့် port ကြိုတင်ဖြည့်ထားလျက် ပြသပေးမည်။ (LAN လိပ်စာလည်း အကျုံးဝင်သည် — ဤ callback အတွက် `192.168.x.x` ကို localhost ဟု မသတ်မှတ်ပါ။) Antigravity ကို အဝေးရှိ OmniRoute နှင့် ချိတ်ဆက်ရန် ပံ့ပိုးထားသော နည်းလမ်းနှစ်ခုရှိသည်။ ### ရွေးချယ်စရာ A — local login helper (အကြံပြုထားသည်) `127.0.0.1` ကို ဝင်ရောက်နိုင်သည့် **သင့်ကိုယ်ပိုင်ကွန်ပျူတာ** ပေါ်တွင် OAuth ကို လုပ်ဆောင်ပါ။ Helper သည် Google နှင့် တိုက်ရိုက်ဆက်သွယ်သောကြောင့် dashboard ဗားရှင်းဖြင့် မပြီးမြောက်နိုင်သော သဘောတူညီမှုကို ထိုစက်ပေါ်တွင် ပြီးမြောက်စေသည်။ **ချိတ်ဆက်ထားပြီးဖြစ်ပါက** (`omniroute connect `) ကူးယူရန် ဘာမျှမလိုပါ — helper က credential ကို ထို install ထံ အလိုအလျောက် ပို့ပေးသည်။ ```bash # သင့် LOCAL စက်ပေါ်တွင် (Node.js + browser လိုအပ်သည်): omniroute connect 192.168.0.15 # တစ်ကြိမ်သာ — admin-scoped context token တစ်ခု ထုတ်ပေးသည် npx omniroute login antigravity # ↳ Google သဘောတူညီချက်ကို ဖွင့်ပြီး local loopback port တွင် callback ကို လက်ခံကာ၊ # exchange ပြုလုပ်ပြီး credential ကို လက်ရှိ context သို့ POST လုပ်သည်: # # Antigravity ကို http://192.168.0.15:20128 တွင် ချိတ်ဆက်ပြီးပါပြီ (ချိတ်ဆက်မှု abc123)။ # Paste လုပ်စရာမလိုပါ — ဤ terminal ကို ပိတ်နိုင်ပါပြီ။ ``` လက်ရှိ context က အခြားစက်တစ်လုံးကို ညွှန်ပြသည့်အခါတိုင်း push ကို အလိုအလျောက် လုပ်ဆောင်သည်။ မည်သည့်အခြေအနေတွင်မဆို အတင်းအကျပ်သတ်မှတ်ရန် `--push` / `--no-push` ကို အသုံးပြုပါ၊ သို့မဟုတ် သီးခြား context တစ်ခုကို ရည်ညွှန်းရန် `--context ` ကို အသုံးပြုပါ။ **သင့်စက်မှ VPS ကို ဝင်ရောက်၍မရပါက** (firewall ဖြင့် ပိတ်ထားခြင်း၊ SSH မရှိခြင်း၊ အင်တာနက်ကွန်ရက်မှ သီးခြားခွဲထားသော အလုပ်နေရာဖြစ်ခြင်း) helper ကို အသုံးပြုနိုင်သေးသည် — ၎င်းသည် Google ကိုသာ အမှန်တကယ် _လိုအပ်_သည်။ `--no-push` ကို အသုံးပြုပါ၊ သို့မဟုတ် push မအောင်မြင်စေရန် ထားလိုက်ပါ။ သင်ပြီးမြောက်ထားသည့် authorization ကို စွန့်ပစ်မည့်အစား blob ကို ထုတ်ပြသည့်နည်းသို့ အလိုအလျောက် ပြောင်းသွားမည်။ ```bash npx omniroute login antigravity --no-push # omniroute-cred-v1.eyJ2IjoxLCJ... ``` ထို့နောက် **အဝေးရှိ** dashboard တွင် **Providers → Antigravity → Connect** သို့သွားပြီး `omniroute-cred-v1.…` blob ကို **Step 2** အကွက်ထဲသို့ paste လုပ်ပါ (callback URL သို့မဟုတ် credential blob နှစ်မျိုးစလုံးကို လက်ခံသည်)။ OmniRoute က ၎င်းကို decode လုပ်ပြီး Cloud Code onboarding ကို server ဘက်တွင် လုပ်ဆောင်ကာ ချိတ်ဆက်မှုကို အမြဲတမ်း သိမ်းဆည်းပေးသည်။ > Blob တွင် refresh token ပါဝင်သောကြောင့် password တစ်ခုကဲ့သို့ သဘောထားပါ။ Push > နည်းလမ်းတွင် ၎င်းကို သင့် context ၏ authenticated connection မှတစ်ဆင့် တစ်ကြိမ်သာ > ပို့သည်။ Paste နည်းလမ်းတွင် သင့် dashboard connection မှတစ်ဆင့် ပို့သည်။ မည်သည့် > နည်းလမ်းကို အသုံးပြုသည်ဖြစ်စေ သိမ်းဆည်းထားချိန်တွင် encryption လုပ်ထားပြီး၊ > အောင်မြင်သော push သည် ၎င်းကို သင့် terminal တွင် လုံးဝ ထုတ်မပြပါ။ Flags: `--no-browser` (အလိုအလျောက်ဖွင့်မည့်အစား URL ကို ထုတ်ပြရန်), `--port ` (loopback port ကို ပုံသေသတ်မှတ်ရန်), `--timeout `, `--push` / `--no-push` (အလိုအလျောက်ပို့ဆောင်မှုကို override လုပ်ရန်), `--context ` (သီးခြား context တစ်ခုကို ရည်ညွှန်းရန်)။ ### ရွေးချယ်စရာ B — SSH local-forward tunnel VPS သို့ SSH ဖြင့် ဝင်ရောက်ခွင့်ရှိပါက loopback callback သည် tunnel မှတစ်ဆင့် server သို့ ပြန်လည်ရောက်ရှိစေရန် dashboard port ကို forward လုပ်ပါ။ ```bash # သင့် LOCAL စက်ပေါ်တွင်: ssh -L 20128:127.0.0.1:20128 user@your-vps # ထို့နောက် သင့် LOCAL browser တွင် http://localhost:20128 ကို ဖွင့်ပြီး Antigravity ကို # ပုံမှန်အတိုင်း ချိတ်ဆက်ပါ — 127.0.0.1:20128/callback redirect သည် ယခုအခါ SSH မှတစ်ဆင့် VPS သို့ ရောက်ရှိမည်။ ``` Dashboard ကို `localhost:20128` ဖြင့် ဝင်ရောက်သောကြောင့် Google သဘောတူညီမှု ပြီးမြောက်ပြီး callback ကို တူညီသော tunnel မှတစ်ဆင့် server သို့ ပို့ပေးသည် — blob မလိုအပ်ပါ။ ချိတ်ဆက်မှု active ဖြစ်ကြောင်း ပြသသည်အထိ tunnel ကို ဖွင့်ထားပါ။ အောက်ပါ fixed-loopback provider များနှင့် မတူဘဲ ဤနေရာတွင် **forward တစ်ခုတည်းနှင့် လုံလောက်သည်**။ Antigravity callback သည် dashboard port ကိုယ်တိုင်မှ ဖြတ်သန်းသောကြောင့် tunnel လုပ်ရန် ဒုတိယ provider-specific port မလိုအပ်ပါ။ > လုံးဝ headless ဖြစ်သော အခြားနည်းလမ်းတစ်ခုအဖြစ် (helper မလို၊ tunnel မလို) > သင့်**ကိုယ်ပိုင်** Google OAuth web credentials + public base URL ကို > configure လုပ်နိုင်သည်။ Provider ၏ OAuth environment variables ကို ကြည့်ပါ။ > အထက်ပါရွေးချယ်စရာနှစ်ခုအတွက် Google ဘက်တွင် ထပ်မံ setup လုပ်ရန် မလိုအပ်ပါ။ --- ## အဝေးထိန်းစက်တွင် ထည့်သွင်းထားသော Codex / Grok ကို ချိတ်ဆက်ခြင်း (သတ်မှတ်ထားသော loopback ပံ့ပိုးသူများ) Codex၊ xAI (`xai-oauth`) နှင့် Grok CLI (`grok-cli`) တို့သည် ၎င်းတို့၏ upstream OAuth app တွင် **ပုံသေသတ်မှတ်ထားသော** loopback `redirect_uri` ကို မှတ်ပုံတင်ထားသည်။ OmniRoute က ၎င်းကို ပြောင်းလဲ၍မရပါ — ပံ့ပိုးသူသည် browser ကို အမြဲတမ်း တူညီသော hardcoded လိပ်စာသို့ ပြန်ပို့သည်- | ပံ့ပိုးသူ | ပံ့ပိုးသူက ပြန်လည်ညွှန်းပို့သည့် ပုံသေ callback | | ----------- | ----------------------------------------------- | | `codex` | `http://localhost:1455/auth/callback` | | `xai-oauth` | `http://127.0.0.1:56121/callback` | | `grok-cli` | `http://127.0.0.1:56122/callback` | ဤနေရာရှိ `localhost` သည် **browser လည်ပတ်နေသော စက်** ကို ဆိုလိုပြီး၊ OmniRoute ၏ PKCE callback server ကတော့ **server ၏** loopback တွင် စောင့်ကြည့်နေသည်။ Dashboard ကို `http://192.168.0.15:20128` ကဲ့သို့သော LAN လိပ်စာဖြင့် ဖွင့်ပါက ၎င်းနှစ်ခုသည် ဘယ်တော့မှ မဆုံနိုင်ပါ။ Authorization code ကို သင့် laptop ၏ `localhost:1455` သို့ ပို့ပေးသော်လည်း ထိုနေရာတွင် မည်သည့်အရာကမျှ စောင့်ကြည့်မနေသောကြောင့် ပံ့ပိုးသူသည် အမှားကို မဖော်ပြဘဲ ဝင်ရောက်မှုကို မအောင်မြင်စေပါသည်။ Dashboard သည် popup ကို မဖွင့်မီ ဤအခြေအနေကို စစ်ဆေးသိရှိပြီး၊ login ကို အမှားမပြဘဲ ပျက်ကွက်စေမည့်အစား tunnel command ကို ပြသပေးသည် (#8046)။ ### ဖြေရှင်းနည်း — port **နှစ်ခုလုံး** ကို forward လုပ်ပါ ```bash # BROWSER လည်ပတ်နေသော စက်ပေါ်တွင်- ssh -L 20128:127.0.0.1:20128 -L 1455:127.0.0.1:1455 @192.168.0.15 # ထို့နောက် http://localhost:20128 သို့ သွားပြီး ထိုနေရာမှ Codex ကို ချိတ်ဆက်ပါ ``` Forward နှစ်ခု လိုအပ်ပြီး၊ တစ်ခုတည်းကိုသာ forward လုပ်ပါကလည်း မအောင်မြင်ပါ- - **`20128`** (dashboard port) သည် origin ကို အမှန်တကယ် local ဖြစ်သော localhost ဖြစ်စေပြီး၊ ထိုသို့ဖြစ်မှသာ OmniRoute သည် PKCE callback server ကို စတင်မည်ဖြစ်သည် — LAN origin သည် ထို branch သို့ ဘယ်တော့မှ မရောက်ပါ။ - **`1455`** (ပံ့ပိုးသူ၏ ပုံသေ callback port) သည် browser ကို ပြန်ပို့သည့်နေရာဖြစ်ပြီး server ၏ loopback သို့ tunnel မှတစ်ဆင့် ရောက်ရှိရမည်ဖြစ်သည်။ xAI သို့မဟုတ် Grok CLI ကို ချိတ်ဆက်သည့်အခါ `1455` ကို `56121`/`56122` ဖြင့်၊ `20128` ကိုလည်း သင့် dashboard port အမှန်ဖြင့် အစားထိုးပါ။ ချိတ်ဆက်မှု active ဖြစ်ကြောင်း ပြသသည်အထိ tunnel ကို ဖွင့်ထားပါ။ > **SSH access မရှိပါသလား။** Codex နှင့် Grok CLI တို့သည် paste လုပ်ထားသော token ကိုလည်း လက်ခံသည် — ချိတ်ဆက်မှု dialog ရှိ **Paste API > Key** / **Import auth.json** tab ကို အသုံးပြုပါ။ ဤနည်းလမ်းတွင် loopback > callback မရှိသောကြောင့် မည်သည့် origin မှမဆို အသုံးပြုနိုင်သည်။ ထို့အပြင် Codex သည် access > token သီးသန့် သို့မဟုတ် `~/.codex/auth.json` session blob ကိုလည်း လက်ခံသည်။ --- ## Token များကို စီမံခြင်း ```bash omniroute tokens create --name "laptop" --scope write [--expires 30] # ↳ secret ကို တစ်ကြိမ်သာ ပြသသည် — ယခုပဲ ကူးယူပါ omniroute tokens list # masked: id, name, scope, prefix, status, expiry omniroute tokens revoke # ချက်ချင်း ပြန်ရုပ်သိမ်းပါ omniroute tokens scopes # scope သုံးမျိုးကို ရှင်းပြသည် ``` `tokens` command များသည် **admin** credential လိုအပ်သည်။ Dashboard ရှိ **Settings → Access Tokens** တွင်လည်း token များကို စီမံနိုင်သည် (ဖန်တီးခြင်း၊ ပြန်ရုပ်သိမ်းခြင်း၊ တစ်ကြိမ်သာ ကူးယူခြင်း)။ Token ကို ဖန်တီးသူ ထားရှိသော privilege ထက် ပိုမိုသော privilege ဖြင့် ဘယ်တော့မှ ထုတ်ပေးနိုင်မည် မဟုတ်ပါ။ `admin` token ကို operator သာလျှင် ဖန်တီးနိုင်သည် — dashboard session၊ server ပေါ်ရှိ local CLI၊ သို့မဟုတ် password ဖြင့် `omniroute connect`။ Machine credential များ (`admin` access token၊ သို့မဟုတ် `manage`/`admin` scope ပါသော API key) သည် `write` နှင့် `read` token များကိုသာ ထုတ်နိုင်သည်; ၎င်းတို့က `--scope admin` တောင်းပါက `403` ပြန်ရသည်။ Login ပိတ်ခြင်းက token ထုတ်ခွင့်ကို မဖွင့်ပေးပါ — မည်သည့် scope ရှိ access token မဆို always-authenticated route များက လက်ခံသော credential ဖြစ်သောကြောင့် အမည်မသိ ခေါ်ဆိုမှုသည် မည်သည့် scope တွင်မဆို `401` ရရှိသည်။ --- ## Remote catalog မှ coding CLI ကို ပြင်ဆင်ခြင်း `omniroute configure` သည် **active server** ၏ live model catalog ကို ဖတ်ပြီး **သင့်** စက်တွင် config ကို ရေးသည်။ ```bash omniroute configure codex # Providers: glm, kmc, ollamacloud, opencode-go, … # Provider: glm # Model id: glm/glm-5.2 # ✔ ~/.codex/glm52.config.toml ကို ရေးပြီးပါပြီ # အသုံးပြုရန်: codex --profile glm52 # non-interactive omniroute configure codex --provider glm --model glm/glm-5.2 --name glm52 # မကြာခဏ သုံးသော model ကို interactive picker ထိပ်တွင် ထားရန် omniroute configure codex --provider glm --model glm/glm-5.2 --favorite --yes ``` Picker သည် model ID များသာ (URL သို့မဟုတ် credential ဘယ်တော့မှ မဟုတ်) ကို context နှင့် CLI target အလိုက် ခွဲထားသော local `model-preferences.json` ဖိုင်တွင် သိမ်းသည်။ Favorite များကို recent selection များထက် အရင်ပြသည်; ထို context/target list မှ ရွေးထားသော model ကို ဖယ်ရှားရန် `--unfavorite` ကို သုံးပါ။ ရေးထားသော profile သည် inference key ကို env var (`OMNIROUTE_API_KEY`) ဖြင့် ရည်ညွှန်းသည် — secret ကို disk ပေါ်တွင် ဘယ်တော့မှ မရေးပါ။ Codex ၏ အကြိမ်တစ်ကြိမ်တည်းသော base setup (`[model_providers.omniroute]` block) အတွက်တော့ [CODEX-CLI-CONFIGURATION.md](./CODEX-CLI-CONFIGURATION.md) ကို ကြည့်ပါ။ ### Config မရေးဘဲ remote သို့ CLI ကို စတင်ခြင်း `omniroute run ` သည် active context ကိုလည်း လေးစားသည်: remote base URL နှင့် context credential ကို စတင်လိုက်သော process ထဲသို့သာ inject လုပ်သည်။ ```bash omniroute connect 192.168.0.15 omniroute run claude --model openai/gpt-5.4 # Claude Code → remote omniroute run gemini --model glm/glm-5.2 -- --skip-trust -p "hello" omniroute run opencode --model glm/glm-5.2 -- run "reply OK" # မစတင်မီ ဘာတွေ စတင်မည်ကို အတိအကျ ကြည့်ရန် (env KEY အမည်များသာ၊ တန်ဖိုးများ မဟုတ်)။ omniroute run codex --dry-run --json ``` Target များ: `claude`၊ `codex`၊ `aider`၊ `goose`၊ `opencode`၊ `qwen`၊ `gemini` (တစ်ခုတည်းသော source: `bin/cli/cli-manifest.mjs`)။ Qwen နှင့် Gemini ကို ထွက်သည်နှင့် ဖျက်ပစ်သော ယာယီ isolated home ဖြင့် run လုပ်သည်၊ ထို့ကြောင့် launch သည် သင့်ကိုယ်ပိုင် tool config ကို ဘယ်တော့မှ မထိ၊ မယိုစိမ့်ပါ။ ### CLI တစ်ခုစီအတွက် setup command များ ထောက်ပံ့သော CLI တစ်ခုစီတွင် remote-aware setup command ရှိသည် (အားလုံးက active context ကို လေးစားသည်၊ သို့မဟုတ် `--remote --api-key `): | CLI | Command | ရေးသားသည့်အရာ | | ----------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Codex | `omniroute setup-codex` | `~/.codex/.config.toml` profile များ (model တစ်ခုစီအလိုက်) | | Claude Code | `omniroute setup-claude` | `~/.claude/profiles//settings.json` (model တစ်ခုစီအလိုက်) | | OpenCode | `omniroute setup-opencode` | `~/.config/opencode/opencode.json` — catalog model အားလုံးပါသော `omniroute` openai-compatible provider (`opencode -m omniroute/` ဖြင့် run ပါ) | | Cline | `omniroute setup-cline` | `~/.cline/data/{globalState,secrets}.json` (CLI mode) + ကူးထည့်ရန် VS Code extension settings ကို ပြသသည် (OpenAI-compatible၊ Base URL **`/v1` မပါဘဲ**) | | Kilo Code | `omniroute setup-kilo` | `~/.local/share/kilo/auth.json` (CLI) + VS Code `kilocode.*` settings — OpenAI-compatible၊ Base URL **`/v1` ပါဝင်ခြင်းဖြင့်** | | Continue | `omniroute setup-continue` | `~/.continue/config.yaml` (VS Code/JetBrains + `cn` CLI) — `provider: openai`၊ `apiBase` **`/v1` ပါဝင်ခြင်းဖြင့်**၊ key ကို `${{ secrets.OMNIROUTE_API_KEY }}` ဖြင့် | | Cursor | `omniroute setup-cursor` | in-app အဆင့်များကို ပြသသည် (Settings → Models → Override OpenAI Base URL **`/v1` ပါဝင်ခြင်းဖြင့်** + key + model)။ Cursor config သည် opaque SQLite ဖြစ်သည် — chat panel သာ | | Roo Code | `omniroute setup-roo` | Roo import JSON ကို ရေးသည် (`~/.omniroute/roo-settings.json`) + `roo-cline.autoImportSettingsPath` ကို သတ်မှတ်ပြီး UI အဆင့်များကို ပြသသည် (OpenAI-compatible၊ Base URL **`/v1` ပါဝင်ခြင်းဖြင့်**) | | Crush | `omniroute setup-crush` | `~/.config/crush/crush.json` — `openai-compat` provider၊ `base_url` **`/v1` ပါဝင်ခြင်းဖြင့်**၊ key ကို `$OMNIROUTE_API_KEY` ဖြင့် | | Zed | `omniroute setup-zed` | `~/.config/zed/settings.json` — `language_models.openai_compatible.omniroute`၊ `api_url` **`/v1` ပါဝင်ခြင်းဖြင့်**၊ key ကို Zed က `$OMNIROUTE_API_KEY` မှ ဖတ်သည် (ဘယ်တော့မှ မရေးပါ) | | Goose | `omniroute setup-goose` | `~/.config/goose/config.yaml` (`GOOSE_PROVIDER=openai` + `OPENAI_HOST` **`/v1` မပါဘဲ** + `GOOSE_MODEL`) + env recipe | | Aider | `omniroute setup-aider` | `~/.aider.conf.yml` (`openai-api-base` **`/v1` မပါဘဲ** + `model: openai/`) + env recipe (`aider --message --yes`) | | Qwen Code | `omniroute setup-qwen` | `~/.qwen/settings.json` V4 `modelProviders.openai` entry + `~/.qwen/.env` ထဲတွင် `OMNIROUTE_API_KEY` | ```bash # OpenCode (openai-compatible provider၊ catalog model အားလုံး၊ remote VPS) omniroute setup-opencode --remote http://192.168.0.15:20128 --api-key oma_live_xxx omniroute setup-opencode --only glm,kimi # ကိုက်ညီသော model များကိုသာ ထားရန် opencode -m omniroute/glm/glm-5.2 "..." # ဦးစွာ OMNIROUTE_API_KEY ကို export လုပ်ပါ ``` --- > OpenCode တွင် ပိုကြွယ်ဝသော **plugin** ပေါင်းစပ်မှုလည်း ရှိသည်: `omniroute setup opencode` (ယခု `--remote` ဖြင့် remote-aware ဖြစ်သည်) သည် `@omniroute/opencode-plugin` ကို ထည့်သွင်းသည်။ > `setup-opencode` သည် ပေါ့ပါးသော openai-compatible အစားထိုးနည်းဖြစ်သည်။ API key ကို `{env:OMNIROUTE_API_KEY}` ဖြင့် ရည်ညွှန်းပြီး ဘယ်တော့မှ disk ပေါ်တွင် မရေးပါ။ > > OpenCode v2 တွင် `@omniroute/opencode-plugin-v2` ကို အစားသုံးပါ: catalog တူညီသော်လည်း loader contract မတူပါ။ ၎င်းသည် ပေါင်းစပ်မှု ချိတ်ဆက်ထားသောအခါ OpenCode ၏ကိုယ်ပိုင် credential store မှ key ကို ဖတ်ပြီး ထို့ကြောင့် remote gateway သည် `opencode.json` တွင် key မလိုအပ်ပါ။ --- ## Context များ စီမံခန့်ခွဲခြင်း (ဆာဗာများအကြား ပြောင်းလဲခြင်း) **Context** ဆိုသည်မှာ သိမ်းဆည်းထားသော ဆာဗာ (baseUrl + credential + scope) တစ်ခုဖြစ်သည်။ `omniroute connect` သည် context တစ်ခုကို ဖန်တီးပြီး ၎င်းကို active ဖြစ်စေသည်။ ထိုအချိန်မှစ၍ command တိုင်းသည် ၎င်းကို ပစ်မှတ်ထားသည်။ ၎င်းတို့ကို `omniroute contexts` ဖြင့် စီမံခန့်ခွဲပြီး ပြောင်းလဲနိုင်သည်- ```bash omniroute contexts list # context အားလုံး; active ဖြစ်နေသော context ကို ● ဖြင့် မှတ်သားထားသည် omniroute contexts current # active ဖြစ်နေသော ဆာဗာ၊ authentication အခြေအနေ၊ scope ``` ```text | Name | Base URL | Auth | Scope | Description ● | vps | http://100.67.86.91:20128 | token | admin | Remote OmniRoute (…) | default | http://localhost:20128 | ✗ | | ``` **ဆာဗာများ ပြောင်းလဲခြင်း** — နောက်ဆက်တွဲ command တိုင်းသည် active context ကို လိုက်နာသည်- ```bash omniroute contexts use vps # → command အားလုံးသည် ယခုအခါ remote VPS ကို ရောက်ရှိသွားသည် omniroute tokens list # (VPS တွင် လုပ်ဆောင်သည်) omniroute contexts use default # → localhost သို့ ပြန်သွားသည် omniroute tokens list # (local server တွင် လုပ်ဆောင်သည်) ``` **Context တစ်ခုကို ကိုယ်တိုင် ထည့်သွင်းခြင်း** (`connect` အစား)၊ စစ်ဆေးခြင်း သို့မဟုတ် အမည်ပြောင်းလဲခြင်း- ```bash omniroute contexts add staging --url https://staging.example.com:20128 \ --access-token oma_live_xxxx --scope write --description "staging box" omniroute contexts show staging # context တစ်ခုအတွက် အသေးစိတ်အချက်အလက်များ omniroute contexts rename staging stg ``` **Context တစ်ခုကို ဖယ်ရှားခြင်း** — အတည်ပြုရန် တောင်းဆိုသည်။ ၎င်းကို ကျော်ရန် `--yes` ကို ထည့်သွင်းပါ (script များ / non-interactive shell များအတွက် လိုအပ်သည်၊ ၎င်းတို့သည် အခြားနည်းဖြင့် လုံခြုံစွာ ငြင်းပယ်သည်)- ```bash omniroute contexts remove stg --yes ``` > `default` (localhost) ကို ဖယ်ရှား၍မရပါ။ active context ကို ဖယ်ရှားခြင်းသည် `default` သို့ ပြန်လည်ရောက်ရှိစေသည်။ အကြံပြုချက်- context တစ်ခုကို ဖယ်ရှားခြင်းသည် **local** တွင် သိမ်းဆည်းထားသော credential ကိုသာ ဖယ်ရှားခြင်းဖြစ်သည်။ ဝင်ရောက်ခွင့်ကို အမှန်တကယ် ပိတ်ရန် ဆာဗာပေါ်ရှိ token ကို `omniroute tokens revoke ` ဖြင့် ရုပ်သိမ်းပါ။ **Context များ Export / Import လုပ်ခြင်း** (ဥပမာ- စက်များအကြား ရွှေ့ပြောင်းရန်)။ Export များသည် မူရင်းအတိုင်း credential များကို ချန်လှပ်ထားသည်၊ ၎င်းတွင် file fallback ဖြင့် သိမ်းဆည်းထားသော credential များလည်း ပါဝင်သည်။ သယ်ဆောင်ရလွယ်ကူသော credential ပါဝင်သည့် backup လိုအပ်သည့်အခါ `--include-secrets` ကို ရှင်းရှင်းလင်းလင်း အသုံးပြုပါ- ```bash omniroute contexts export --out contexts.json # ဖျက်ထားသည်; မူရင်း ဦးတည်ရာ- stdout omniroute contexts export --include-secrets --out private-contexts.json omniroute contexts import contexts.json # ထပ်ရေးသည်; ရှိပြီးသားများကို ထိန်းသိမ်းရန် --merge omniroute contexts migrate --yes # အဟောင်း plaintext token များကို keychain သို့ ရွှေ့ပြောင်းသည် ``` `--include-secrets` သည် export မလုပ်မီ keychain reference များကို ဖြေရှင်းပြီး ကိုးကားထားသော credential တစ်ခုခုကို ဖတ်၍မရပါက ပျက်ကွက်သည်။ `--no-secrets` သည် အမြဲတမ်း ဦးစားပေးသည်။ Export file များကို mode `0600` ဖြင့် atomically ရေးသားသည်။ ရှင်းလင်းသော secret ပါဝင်သည့် export ကို လျှို့ဝှက်ပစ္စည်းအဖြစ် သတ်မှတ်ပါ။ အသုံးပြုနိုင်သော OS keychain မရှိသော headless system များတွင် CLI သည် mode `0600` ဖြင့် `config.json` သို့ ပြန်လည်ရောက်ရှိပြီး တစ်ကြိမ်သာ သတိပေးချက်ကို ပုံနှိပ်သည်။ ဤ mode တွင် default export သည် ဖျက်ထားဆဲဖြစ်သည်။ --- ## အစမှအဆုံး အမြန်စစ်ဆေးခြင်း Remote setup တစ်ခုကို အစမှ စစ်ဆေးရန် copy-paste လုပ်နိုင်သော lifecycle — ချိတ်ဆက်ခြင်း၊ scope သတ်မှတ်ထားသော token ထုတ်ပေးခြင်း၊ command တစ်ခုကို လမ်းကြောင်းပေးခြင်း၊ ပြန်ပြောင်းခြင်းနှင့် ဖြုတ်သိမ်းခြင်း။ `192.168.0.15` ကို သင့် server ၏ host/IP (Tailscale၊ LAN သို့မဟုတ် အများသုံး `https://…` URL) ဖြင့် အစားထိုးပါ။ ```bash # 1. ချိတ်ဆက်ပါ (password → admin token၊ active ဖြစ်လာမည့် context အဖြစ် သိမ်းဆည်းသည်) omniroute connect 192.168.0.15 # သို့မဟုတ်- --key oma_live_xxxx (password မလိုပါ) omniroute contexts current # remote server + scope ကို ပြသသည် # 2. အသုံးပြုပါ — ယခု management command များသည် remote ကို ဦးတည်ပြီး လုပ်ဆောင်သည် omniroute tokens create --name laptop --scope read # ပိုမိုကန့်သတ်ထားသော token တစ်ခု ထုတ်ပေးသည် omniroute tokens list # remote မှ ဖုံးကွယ်ပြသထားသော စာရင်း # 3. အပြန်အလှန် ပြောင်းပါ omniroute contexts use default # → local omniroute contexts use 192-168-0-15 # → remote သို့ ပြန်သွားသည် (`contexts list` မှ အမည်) # 4. ဖြုတ်သိမ်းပါ။ မှတ်ချက်- `contexts remove` သည် LOCAL credential ကိုသာ ဖျက်သည် — # server ပေါ်ရှိ token ကို မရုပ်သိမ်းပါ။ အသုံးပြုခွင့်ကို အမှန်တကယ် ပိတ်လိုပါက server ဘက်တွင် ဦးစွာ # ရုပ်သိမ်းပါ။ omniroute tokens revoke # server ပေါ်ရှိ အသုံးပြုခွင့်ကို ပိတ်သည် omniroute contexts remove 192-168-0-15 --yes # local context ကို ဖျက်သည် (active ဖြစ်နေလျှင်ပင် → default သို့ ပြန်သွားသည်)၊ အတည်ပြုချက် မတောင်းပါ ``` > `--yes` သည် `contexts remove` ကို non-interactive ဖြစ်စေသည် (scripts/CI တွင် လိုအပ်သည်၊ > မပါလျှင် non-interactive shell သည် ရပ်ဆိုင်းစောင့်ဆိုင်းမည့်အစား ဘေးကင်းစွာ ငြင်းပယ်သည်)။ **active** > context ကို ဖယ်ရှားပါက `default` သို့ အလိုအလျောက် ပြန်သွားမည်။ --- ## လုံခြုံရေးဆိုင်ရာ မှတ်ချက်များ - Token စာသားအကြမ်းကို တစ်ကြိမ်သာ ပြသသည်။ SHA-256 hash ကိုသာ အမြဲတမ်း သိမ်းဆည်းထားသည် (API key များနှင့် အတူတူဖြစ်သည်)။ - `omniroute connect` သည် login ကို ဆက်တိုက် အကြိမ်ကြိမ် ခန့်မှန်းဝင်ရောက်ရန် ကြိုးပမ်းမှုအား ပိတ်ဆို့ခြင်းနှင့် audit logging ကို ပြန်လည်အသုံးပြုသည်။ - ပို့ဆောင်ရေးအတွက် HTTPS သို့မဟုတ် Tailnet ကို ဦးစားပေးအသုံးပြုပါ။ host သီးသန့်သာ ပေးထားပါက LAN/Tailscale တွင် အဆင်ပြေစေရန် မူလသတ်မှတ်ချက်အရ `http://` ကို အသုံးပြုသည် — TLS အတွက် `https://…` URL အပြည့်အစုံကို ပေးပါ။ - ဦးစားပေးအသုံးပြုသည့် local context file သည် `~/.omniroute/config.json` (`chmod 600`) ဖြစ်ပြီး `credentialRef` တစ်ခုသာ ပါဝင်သည်။ Token ကိုယ်တိုင်ကို OS keychain (`keytar`) တွင် သိမ်းဆည်းထားပြီး log များတွင် မည်သည့်အခါမျှ ဖော်ပြခြင်းမရှိပါ။ အလုပ်လုပ်သည့် native keychain မရှိသော headless installation များသည် တူညီသော `0600` file ကို ရှင်းလင်းစွာ သတ်မှတ်ထားသည့် fallback အဖြစ် အသုံးပြုပြီး သတိပေးချက်ကို တစ်ကြိမ် ထုတ်ပြန်သည်။ Keychain backend ကို ထည့်သွင်းပြီးနောက် `omniroute contexts migrate --yes` ကို အသုံးပြုပါ။ --- ## API endpoint များ (ကိုးကားရန်) | နည်းလမ်း | လမ်းကြောင်း | အထောက်အထားစိစစ်မှု | လုပ်ပိုင်ခွင့်အတိုင်းအတာ | | -------- | --------------------- | ----------------------- | ------------------------------------------- | | POST | `/api/cli/connect` | စီမံခန့်ခွဲမှု password | — (အများသုံး၊ password ဖြင့် ကန့်သတ်ထားသည်) | | GET | `/api/cli/whoami` | access token | ဖတ်ရှုခြင်း | | GET | `/api/cli/tokens` | access token | စီမံခန့်ခွဲမှု | | POST | `/api/cli/tokens` | access token | စီမံခန့်ခွဲမှု | | DELETE | `/api/cli/tokens/:id` | access token | စီမံခန့်ခွဲမှု | Schema အပြည့်အစုံအတွက် [openapi.yaml](../openapi.yaml) ကို ကြည့်ပါ။