prompt/tool mismatch: gpt-6-astra preset demands apply_patch for prefixed ids (codex/gpt-6-astra) but tool gate returns wireMode none - editing deadlocks

[brianmok888]

Summary

Two senpi built-ins disagree about how to match GPT model ids, which can deadlock editing on gateway-prefixed ids.

• The prompt-preset resolver recognizes prefixed ids like codex/gpt-6-astra (boundary-aware regex), selects the gpt-6-astra preset, and injects: "Use apply_patch for ALL file edits and creations."
• The gpt-apply-patch tool gate uses a literal prefix check model.id.startsWith("gpt-"), so the same prefixed id gets wireMode: "none" → the tool is registered but never activated, and lazy activation is refused.

Result: the generated developer instructions exclusively require a tool that the runtime reports as Tool apply_patch is registered but inactive — sessions refuse to edit via write/edit and stall.

Environment

• @code-yeongyu/senpi 2026.9.19-2 (bun global install)
• Provider: OpenAI-compatible gateway exposing codex/gpt-6-astra with api: "openai-completions"
• Baseline session model glm/glm-5.3, switched mid-session to codex/gpt-6-astra
• promptPreset: "auto"

Repro

Runtime repro against installed resolvePreset / getApplyPatchWireMode (selected tools read, edit, write):

Model ID	API	Selected preset	Contains patch-only instruction	Patch wire mode
glm/glm-5.3	openai-completions	glm-5.3	No	none
codex/gpt-6-astra	openai-completions	gpt-6-astra	Yes	none
gpt-6-astra	openai-completions	gpt-6-astra	Yes	json

Extension-API mock (session_start with GLM → model_select with the prefixed astra id):

Registered:      apply_patch
Active:          read, edit, write
Lazy activation: false

Live symptom: calling the tool raises Tool apply_patch is registered but inactive. Active tools: read, edit, write, ...

Source references (installed 2026.9.19-2)

• dist/core/extensions/builtin/prompt-preset/presets.js:36-40 — boundary-aware hasGpt6AstraSignal regex; :213-214 selects the preset
• dist/core/extensions/builtin/prompt-preset/gpt-6-astra.js:259 — calls buildFileOperationsTuning()
• dist/core/extensions/builtin/prompt-preset/file-operations.js:23 — "Use apply_patch for ALL file edits and creations."
• dist/core/extensions/builtin/gpt-apply-patch/extension.js:9-20 — isGptId literal startsWith("gpt-"); :75-84 refuses lazy activation when wireMode === "none"
• dist/core/agent-session.js:2223-2225 — emits inactive_tool / "registered but inactive"

Suggested direction

1. Make the two matchers consistent (e.g. boundary-aware isGptId, mirroring the preset matcher, for prefixed gateway ids).
2. Or make the file-operations tuning conditional on the tool actually being activatable for the current model+API.
3. Preserve correct patch serialization for the selected API; merely force-enabling a registered variant does not establish correct format selection.
4. Add regression coverage: bare vs prefixed GPT ids, supported vs unsupported APIs, non-GPT models, model switches in both directions.
5. Assert the integration contract: a generated prompt must not exclusively require apply_patch when it is inactive and edit/write are the available editing surface.

[brianmok888]

Generalization: this affects any provider-prefixed GPT id, not just codex/gpt-6-astra

The two matchers disagree on prefix handling across the whole GPT family, so any user routing GPT models through a gateway that emits prefixed ids (OpenRouter-style openrouter/gpt-*, opencode/gpt-*, LiteLLM, custom OpenAI-compatible providers) can hit the same deadlock.

Verified against installed 2026.9.19-2:

Preset side is prefix-tolerant (two mechanisms):

1. GPT-6 Astra — presets.js:36-40 boundary regex /(?:^|[/@:._-])gpt[._-]?6[._-]astra(?:$|[/@:._-])/ (after normalizeModelId, presets.js:28-30) matches any / @ : . _ --delimited prefix: openrouter/gpt-6-astra, opencode/gpt-6-astra, global.openai.gpt-6-astra (the latter is explicitly listed as a supported shape in the comment at presets.js:31-34).
2. GPT-5.x family is even looser — extractGpt5Version (presets.js:42-57) uses plain substring matching: normalized.includes("gpt-5.6") etc., so any id containing the substring selects the preset. The gpt-5.6 preset injects the same patch-only rule via buildFileOperationsTuning() (gpt-5.6.js:173).

Tool side is strict: isGptId (gpt-apply-patch/extension.js:9-11) requires literal model.id.startsWith("gpt-"), so every prefixed id fails → wireMode: "none" → registered-but-inactive, regardless of API.

Resulting matrix (openai-completions API):

Model id	Preset selected	Patch-only instruction	apply_patch wireMode	Outcome
gpt-6-astra / gpt-5.6	yes	yes	json	works
codex/gpt-6-astra	yes	yes	none	deadlock
openrouter/gpt-6-astra	yes	yes	none	deadlock
opencode/gpt-5.6	yes	yes	none	deadlock
any prefix/gpt-*	yes	yes	none	deadlock

So the suggested fix direction (boundary-aware isGptId mirroring the preset matcher, and/or making the file-operations tuning conditional on the tool actually being activatable) would need to cover the whole GPT family, not just astra. The substring-based extractGpt5Version also means the tool gate should not rely on a bare-prefix check even after normalization — e.g. a hypothetical id like xgpt-5.6-proxy currently selects the preset via substring but would also fail startsWith("gpt-"), correctly by accident, yet openai/gpt-5.6 fails it wrongly.

[code-yeongyu]

Closed by #1942 (merged as 0150285792), from @MoerAI.

Verified after the merge, across id shapes and APIs:

codex/gpt-6-astra              openai-completions   preset=gpt-6-astra  wireMode=json
codex/gpt-6-astra              openai-responses     preset=gpt-6-astra  wireMode=freeform
codex/gpt-6-astra              anthropic-messages   preset=gpt-6-astra  wireMode=none
openrouter/openai/gpt-5.6-sol  openai-completions   preset=gpt-5.6      wireMode=json
global.openai.gpt-6-astra      openai-completions   preset=gpt-6-astra  wireMode=json
gateway:GPT_6_ASTRA            openai-completions   preset=gpt-6-astra  wireMode=json
gateway/glm-5.3                openai-completions   preset=glm-5.3      wireMode=none
xgpt-5.6-proxy                 openai-completions   preset=gpt-5.6      wireMode=none

Two follow-ups came out of reviewing it.

1. The gate has a second consumer that the PR did not mention. ask-user/family.ts pickVariant() is getApplyPatchWireMode(model) !== "none" ? "codex" : "claude", so widening isGptId also moved provider-prefixed GPT sessions from ask_user_question to request_user_input. That is the correct outcome — a prefixed id should behave like its bare counterpart — but it shipped with no coverage. Added to 1891-prefixed-gpt-patch-tools.test.ts and proven by mutation: reverting isGptId to id.startsWith("gpt-") turns those rows red (10 failed | 6 passed), restoring it returns 16 passed.

2. The prompt half is a wider class, tracked in #1968. This issue's deadlock existed because the ## File operations block was rendered from preset identity rather than from the session's active tools. #1942's conditional wording ends the deadlock but keeps the cause, and the same defect ships today for every Grok 4.5 user. Fixed in #1978.