[FEATURE]: Full air-gapped / offline mode support – disable all non-LLM network access #16117

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Problem:

Many enterprise, government, defense, and high-security environments require fully air-gapped deployments where the application can only make network calls to an internal/local LLM endpoint (e.g. Ollama, vLLM, TGI, or a private OpenAI-compatible gateway at http://internal-llm:8000/v1).

Currently, OpenCode performs several unconditional network fetches on startup / during usage, even when using purely local models:

• Fetch to https://models.dev/api.json (for model/provider discovery) → fails or hangs in no-internet setups
• Potential telemetry / update checks (Oh My OpenCode auto-update attempts)
• Plugin/package manifest downloads (e.g. pyright LSP manifest errors in offline mode)
• Possibly other fetches (e.g. AGENTS.md loading issues reported in offline envs)

Related existing issues (which are close but narrower in scope):

• Suppport for airgapped installation #2224 Suppport for airgapped installation (Aug 2025) – requests general no-network-except-LLM support
• [FEATURE]: Add option to disable models.dev fetch for corporate proxy environments #4959 [FEATURE]: Add option to disable models.dev fetch for corporate proxy environments (Dec 2025) – focuses on proxy + models.dev, but not full lockdown
• AGENTS.md Loading Failure in Offline Environment #5232 AGENTS.md Loading Failure in Offline Environment (Dec 2025)
• When deploying open-source code offline, encountering the error message: "Unable to connect. Is the computer able to access the URL?" #9788 When deploying open-source code offline, encountering the error message: "Unable to connect..." (Jan 2026) – mentions update checks breaking startup
• error: FailedToOpenSocket downloading package manifest pyright #9932 error: FailedToOpenSocket downloading package manifest pyright (Jan 2026)

These show recurring pain in restricted networks, but no comprehensive "offline/air-gapped mode" exists yet.

Solution:

Add a robust offline / air-gapped mode that:

1. Disables all non-LLM outbound network requests when enabled (except the configured baseURL for the model provider).

2. Provides a single, clear toggle, e.g.:

   • Config key: "offline": true or "airgapped": true in opencode.json
   • Environment variable: OPENCODE_OFFLINE=1 or OPENCODE_AIRGAPPED=1
   • CLI flag: opencode --offline / opencode --airgapped

3. When enabled, OpenCode should:

   • Skip the https://models.dev/api.json fetch entirely
   • Skip any auto-update / version checks (Oh My OpenCode, GitHub releases, etc.)
   • Skip external plugin/LSP manifest downloads
   • Skip loading remote resources (e.g. AGENTS.md if fetched remotely)
   • Fall back gracefully to locally available providers/models only (user-defined in opencode.json)
   • Optionally log a clear startup message:
     Air-gapped / offline mode enabled – all external network access disabled except LLM endpoint

4. Bonus / nice-to-have (could be follow-ups):

   • Respect an internal mirror for models list via env var (e.g. OPENCODE_MODELS_URL=http://internal-mirror/api.json) – already partially supported but inconsistent (see [FEATURE]:Build script ignores OPENCODE_MODELS_URL env var #11385)
   • Disable telemetry completely (separate issue Disable Telemetry #5554 exists)
   • Validate that only private/local baseURL patterns are allowed (optional strict mode)

Describe alternatives you've considered

• Manual workarounds: firewall blocks + proxy tricks → unreliable and breaks startup
• Patching the binary/source → high maintenance, not scalable for teams
• Using only custom providers in opencode.json → doesn't prevent the models.dev fetch or other calls

Additional context

This is a common requirement in regulated industries (finance, healthcare, defense, government). A clean, supported offline mode would make OpenCode much more adoptable in these settings without needing heavy forks.

Many users already run successfully with local Ollama/vLLM once the startup fetches are bypassed, so the core engine works great offline — we just need the guardrails.

Thanks for considering this!