ChatGPT Work Integration
Run the ChatGPT desktop app — Chat, Work, and Codex — against Ask Sage
About ChatGPT Work on Ask Sage
ChatGPT Work is OpenAI's agentic mode for producing finished deliverables — spreadsheets, slides, documents, PDFs, and interactive reports — rather than just conversation. It sits alongside Chat and Codex as one of the three modes in the ChatGPT desktop app.
The desktop app is built on Codex. It bundles its own copy of the Codex CLI and drives it, which means it reads the same ~/.codex/config.toml that the standalone CLI uses. Point that file at Ask Sage and everything the app executes locally follows — Work mode included. Your prompts and the model calls behind every locally generated deliverable route through your Ask Sage instance.
api.asksage.ai, serving gpt-6-astra through Work mode. Note that OpenAI's own documentation does not describe this, because it documents ChatGPT on the web — where there is no bring-your-own-model option at all. The desktop app is a different surface. Table of Contents
Instance-Specific Base URL: The endpoints and configuration shown reflect the instance at chat.asksage.ai. The api. prefix and path suffix stay the same across deployments — only the instance segment in the middle changes based on which Ask Sage instance you are logging into. Always use the instance approved by your organization and applicable regulatory requirements, and match the base URL in your configuration to the instance you authenticate against.
What routes where
Setting model_provider at the top level of ~/.codex/config.toml makes Ask Sage the default for work the app runs on this computer — not just for the Codex tab:
| Mode | What it is | Model calls go to (when run locally) |
|---|---|---|
| Chat | Everyday conversation | Ask Sage |
| Work | Multi-step agentic tasks producing deliverables | Ask Sage |
| Codex | Software development with codebase context | Ask Sage |
A local config file can only govern local execution. The desktop app can also run a task in OpenAI's cloud rather than on your machine, and a cloud-executed task never sees ~/.codex/config.toml, so it does not route through Ask Sage. The app decides this per conversation — when it offers to Continue with Work, that is the point at which execution is pinned, and the app indicates whether the conversation is running on your computer.
For a governed deployment, train users to keep Work running locally, and confirm the conversation is marked as running on the device before putting sensitive material into it. Treat the routing guarantee on this page as applying to local execution only.
model_provider being set at the top level. If you instead set the provider only inside a profile, or you leave the top-level model_provider on the default openai, then some or all of the app continues talking to OpenAI. On a CUI, ITAR, or otherwise regulated workload that is a spillage path, and nothing in the interface will tell you it is happening. Verify with the check below rather than assuming. Prerequisites
ChatGPT Desktop App
macOS, Windows, or Linux — from chatgpt.com/download
openai provider, or when a provider sets requires_openai_auth = true. Pointing model_provider at Ask Sage takes neither path, so the app authenticates to Ask Sage with your key and skips OpenAI authentication completely — no ChatGPT subscription, no codex login, and no ~/.codex/auth.json on disk. This is verified: the machines running this configuration have never signed in to OpenAI. Configuration
Edit ~/.codex/config.toml — on Windows, %USERPROFILE%\.codex\config.toml. Create the file if it does not exist. The app rewrites this file at runtime to manage its own plugin and desktop settings, so add these keys to the existing file rather than replacing it.
# Make Ask Sage the default provider for the whole app
model = "gpt-6-astra"
model_provider = "asksage"
model_reasoning_effort = "medium"
# Model Provider — Ask Sage Passthrough
[model_providers.asksage]
name = "AskSage Passthrough"
base_url = "https://api.asksage.ai/server/openai/v1"
wire_api = "responses"
[model_providers.asksage.http_headers]
x-access-tokens = "your-asksage-api-key"Quit the app fully and reopen it. The mode dropdown will offer Chat, Work, and Codex as before, now served by Ask Sage.
export in a shell. Using env_key instead of http_headers produces the confusing result that the codex CLI authenticates fine from your terminal while the desktop app fails — which reads like a bad key rather than a missing one. If you must keep the key out of the file, set it at the OS level with setx on Windows, or launchctl setenv plus a LaunchAgent on macOS. | Setting | Why |
|---|---|
model_provider | Must be at the top level — this is what makes Chat and Work follow, not just Codex. |
base_url | The OpenAI-compatible surface, including the /v1. Omitting it is the single most common misconfiguration. |
wire_api | Must be "responses". Codex dropped Chat Completions support in February 2026. |
x-access-tokens | Ask Sage reads the API key from this header. |
sandbox under a [windows] table, accepting elevated or unelevated. If shell calls fail with CreateProcess ... Rejected(... blocked by policy) — which reads like a corporate group-policy block but is not — set sandbox = "unelevated", which resolved it on the Windows 11 Enterprise builds we tested. macOS has no equivalent setting, so a Mac-tested config copied to Windows can fail here for reasons the error message does not explain. Verify where your traffic is going
1. Prove the endpoint and key work
The model list is public, so it proves reachability but not your credential. Run both — the second is the only real credential test:
# Reachability — no credential needed
curl -s https://api.asksage.ai/server/openai/v1/models | jq '.data[].id'
# Credential test
curl -s -X POST https://api.asksage.ai/server/openai/v1/responses \
-H "Content-Type: application/json" \
-H "x-access-tokens: $ASKSAGE_API_KEY" \
-d '{"model":"gpt-6-astra","input":"reply with OK","max_output_tokens":16}'The second command reads the key from $ASKSAGE_API_KEY rather than taking it inline, so it stays out of your shell history. The app itself reads the key from config.toml, not from the environment, so this variable is only for running these checks — set it for the current shell before you run them:
# macOS / Linux — current shell only
read -rs ASKSAGE_API_KEY && export ASKSAGE_API_KEY
# Windows PowerShell — current session only
$env:ASKSAGE_API_KEY = Read-Host -AsSecureString | ConvertFrom-SecureString -AsPlainText{"response":"Token is invalid [1]","status":400} — not the HTTP status. Read the body. This is why an invalid key surfaces in the app as a vague streaming error instead of an auth error. 2. Confirm the app is using the provider
Check that the top-level provider really is Ask Sage and that no profile is overriding it:
grep -E '^(model|model_provider)' ~/.codex/config.tomlYou want to see model_provider = "asksage". If it says openai, or the line is missing, the app is still going to OpenAI regardless of what the [model_providers.asksage] block says.
3. Confirm it end to end
The authoritative check is on the Ask Sage side: run a prompt in Work mode, then confirm the usage appears against your account in Ask Sage. If tokens are being consumed in Ask Sage, the traffic is genuinely routing through your instance.
Troubleshooting
You are using env_key. The GUI does not inherit shell exports. Move the key into [model_providers.asksage.http_headers] as shown above.
Codex uses this one message for several unrelated faults: a wrong base URL, an invalid key, a model your account cannot access, or an unexported environment variable. Run the curl probe above first — it separates auth failures from routing failures in one step. The most common cause is a base_url missing the /v1 suffix.
Codex has no built-in metadata for that model ID and falls back to defaults. It usually still works, but behaviour can degrade. Switch to one of the recommended models if you see tool-calling problems.
The desktop app owns and rewrites ~/.codex/config.toml to manage plugin and desktop state. Keep a copy of your provider block so you can re-add it, and re-check model_provider after major app updates.
CreateProcess ... Rejected(... blocked by policy) Add sandbox = "unelevated" under [windows]. This is a Codex sandbox default, not your organisation's group policy.
Additional Resources
- Ask Sage — Codex integration — the full configuration reference, hardened profile, and DoD network guidance
- OpenAI — Codex configuration reference
- OpenAI — Codex quickstart
- Ask Sage — API documentation