Goal / Problem
The vision sidecar feature is advertised as a headline capability ("Give any model superpowers - image understanding via gpt-5.4-mini sidecar"), but it is completely unusable from Codex App -- the most common entry point for users. This is not an edge case; it affects every App user who tries to paste an image while using a text-only routed model.
Concrete user workflow that fails:
- User configures a GLM provider (e.g. Volcengine Ark Agent Plan) with
adapter: anthropic, defaultModel: glm-5.2
- User adds
noVisionModels: ["glm-5.2"] to the provider config (as documented)
- User enables vision sidecar:
visionSidecar: { model: "gpt-5.4-mini", backend: "openai" } (as documented)
- User opens Codex App, selects
GLM.MacAgent/glm-5.2 as the active model
- User pastes an image into the conversation
- Codex App immediately rejects the image -- "model does not support image input"
- No request is sent to the OpenCodex proxy
- The vision sidecar never runs
The image never reaches the proxy. The sidecar is dead code for App users.
Why this matters:
- GLM via Volcengine is one of the cheapest high-quality coding models available. Many users route to it through OpenCodex specifically because they want to save OpenAI quota.
- These users have NO way to use images with GLM in Codex App, even though OpenCodex has the infrastructure to make it work.
- The same setup works perfectly in Claude Code -- I have verified this end-to-end. Claude Code does not perform client-side
inputModalities pre-checks, so the image reaches the proxy, the sidecar describes it via gpt-5.4-mini, and GLM answers based on the text description. This proves the sidecar pipeline is sound; only the App's pre-check blocks it.
Expected behaviour
When noVisionModels is configured for a provider AND the vision sidecar is enabled, OpenCodex should advertise inputModalities: ["text", "image"] in the catalog entry for those specific models. This allows the full pipeline to work:
- Codex App sees image support in catalog -> lets the image through
- Request with image reaches OpenCodex proxy
- Vision sidecar activates:
gpt-5.4-mini describes the image
- Text description is fed to the upstream model (GLM/DeepSeek/etc.)
- User gets image understanding end-to-end
Why this is the right place to fix it
The noVisionModels field already signals "this model cannot see images natively, the sidecar should handle it." But the catalog metadata declares inputModalities: ["text"], which tells the App to block images before they can reach the sidecar. These two configs directly contradict each other. The fix is to reconcile them: if the sidecar is configured to cover a model, the catalog should reflect that image input is effectively supported.
Impact
- Affected models: All text-only routed models with
noVisionModels -- GLM, DeepSeek, and any future text-only model users want to use with images
- Affected users: Every Codex App user who routes to a text-only model and expects the advertised vision sidecar to work
- Current workaround: None from the App. Users must switch to Claude Code or CLI to use images with text-only routed models. Manually editing
modelInputModalities is fragile and undocumented.
Verification that the sidecar itself works
I tested the exact same configuration in Claude Code (which routes through the same OpenCodex proxy at http://127.0.0.1:10100):
- Model:
claude-ocx-GLM.MacAgent--glm-5.2
- Pasted an image
- Result: Success -- the sidecar described the image, GLM answered correctly based on the description
- This confirms the sidecar pipeline is fully functional; the only blocker is the App's client-side
inputModalities pre-check
Environment
- opencodex: 2.7.36
- macOS, Apple Silicon
- Codex App + Claude Code (same proxy, same config)
- Provider: GLM.MacAgent (Volcengine Ark Agent Plan, anthropic adapter)
- Sidecar: gpt-5.4-mini via OpenAI (ChatGPT login)
Checks
Goal / Problem
The vision sidecar feature is advertised as a headline capability ("Give any model superpowers - image understanding via gpt-5.4-mini sidecar"), but it is completely unusable from Codex App -- the most common entry point for users. This is not an edge case; it affects every App user who tries to paste an image while using a text-only routed model.
Concrete user workflow that fails:
adapter: anthropic,defaultModel: glm-5.2noVisionModels: ["glm-5.2"]to the provider config (as documented)visionSidecar: { model: "gpt-5.4-mini", backend: "openai" }(as documented)GLM.MacAgent/glm-5.2as the active modelThe image never reaches the proxy. The sidecar is dead code for App users.
Why this matters:
inputModalitiespre-checks, so the image reaches the proxy, the sidecar describes it viagpt-5.4-mini, and GLM answers based on the text description. This proves the sidecar pipeline is sound; only the App's pre-check blocks it.Expected behaviour
When
noVisionModelsis configured for a provider AND the vision sidecar is enabled, OpenCodex should advertiseinputModalities: ["text", "image"]in the catalog entry for those specific models. This allows the full pipeline to work:gpt-5.4-minidescribes the imageWhy this is the right place to fix it
The
noVisionModelsfield already signals "this model cannot see images natively, the sidecar should handle it." But the catalog metadata declaresinputModalities: ["text"], which tells the App to block images before they can reach the sidecar. These two configs directly contradict each other. The fix is to reconcile them: if the sidecar is configured to cover a model, the catalog should reflect that image input is effectively supported.Impact
noVisionModels-- GLM, DeepSeek, and any future text-only model users want to use with imagesmodelInputModalitiesis fragile and undocumented.Verification that the sidecar itself works
I tested the exact same configuration in Claude Code (which routes through the same OpenCodex proxy at
http://127.0.0.1:10100):claude-ocx-GLM.MacAgent--glm-5.2inputModalitiespre-checkEnvironment
Checks