fix(codex,acl): routed reasoning-effort propagation (#1100) and a workable Windows ACL envelope (#1156) by lidge-jun · Pull Request #1197 · lidge-jun/opencodex

lidge-jun · 2026-08-07T08:07:43Z

Summary

Related to #1100 and #1156. Partial remediation of #1100 — do not close that issue on this PR (the reporter's exact endpoint is still unadopted; see below).

Stacked on #1194.

#1100 — reasoning effort never reaches routed DeepSeek and GLM

Catalog generation contradicted itself. src/codex/catalog/effort.ts advertises the effort ladder on routed rows; normalizeRoutedCatalogEntry then deletes supports_reasoning_summaries (parsing.ts:351) and strict normalization defaults it false (:262). Codex reads a row that offers effort levels but declares no summary support, and omits the entire inbound reasoning object. The adapter would serialize reasoning_effort correctly if it ever arrived — nothing downstream is broken.

The delete is not careless: routed rows are cloned from native templates and must not inherit OpenAI-only summary delivery. The comment there anticipates exactly this per-model opt-in.

So the fix supplies registry-side defaults for modelSupportsReasoningSummaries, a config field that already exists (src/types.ts:1235) and that users currently have to set by hand. Opted in only where the registry's own metadata supports it: canonical DeepSeek V4 Flash/Pro, opencode-go's DeepSeek and GLM 5/5.1/5.2, Z.AI GLM 5.2, and the Zhipu models in ZHIPU_BIGMODEL_THINKING_TOGGLE_MODELS. glm-4.7-flash and glm-4.6v are deliberately excluded — they are absent from that set.

Three things audit forced, each worth stating because the first version passed its tests while getting them wrong:

Custom-named providers. Enrichment matches on provider name. The reporter's row is a hand-added provider literally called GLM. Routing worked, so it looked healthy, but no registry id is called GLM, so no metadata arrived. The first version's tests used canonical ids and were green against a configuration no user had. On a name miss we now fall back to registryEntryForProviderDestination, which matches by vendor endpoint and is already restricted to fixed key destinations — no templated or overridable base URL can be claimed by it. Scope is one field.

Per-key, on both paths. The merge cannot be the whole-Record === undefined fill the surrounding scalars use: a user who sets one model's flag creates a defined Record, which would then suppress every registry default. Registry defaults spread first, explicit user keys win — including an explicit false, which someone set because their backend 400s on summaries.

Never persisted. enrichProviderFromCatalog feeds a config about to be written to disk. Freezing today's defaults there would turn them into the user's own overrides, so a later registry correction would never reach anyone who created their provider first. It now restores exactly what the caller submitted. Catalog gathering enriches a detached runtime clone, so the defaults still apply where they matter.

Known remaining gap. The reporter's endpoint, open.bigmodel.cn/api/coding/paas/v4, is in no registry entry — only /api/paas/v4 is. That route still needs the manual modelSupportsReasoningSummaries setting. Closing it requires a new registry entry with a distinct id (glm and glm-cn are bound in FREE_PROVIDER_DIRECTORY, and reusing either would retarget an existing config's endpoint), preserveCustomDestination: true, its own evidence-backed model set, and EXPECTED_KEY_PROVIDER_IDS parity updates. That is a provider adoption, not a bug fix, and is recorded as deferred in the plan unit.

#1156 — Windows ACL harden envelope

On a machine where icacls is slow — Defender real-time scanning, a roaming profile, a domain-controller round trip — a complete ACL sequence could not finish inside the 5-second envelope. The harden failed closed, the native-main owner published a permanent unavailable, and every native request returned 503 until restart.

One correction to the issue's framing: PR #1135's retry is not the problem. Owner-level recovery calls hardenSecret again and does get a fresh deadline. The defect is that one complete sequence — /grant:r, /inheritance:r, /remove:g, plus conditional /findsid — had five seconds for all of it.

Raises the default to 30s, keeping the 60s cap, the OPENCODEX_ACL_TIMEOUT_MS override, the clamp, and the shared-envelope structure. Per-command budgets were rejected: with /findsid fallbacks they multiply into the multi-minute startup stall the shared budget was introduced to prevent.

The cost is in the source comment rather than hidden: because loadConfig hardens three paths sequentially, the timeout-path worst case at load becomes ~90s, and the owner path ~60.25s. Both need icacls to be pathologically slow on every call; a healthy machine finishes in milliseconds. A slow start is recoverable, a permanent 503 is not, and the failure stays fail-closed either way. 15s was considered and rejected — the reported slow-step class leaves it no margin.

Four existing tests depended on the 5s default while actually asserting something else (envelope sharing, fresh-budget-on-second-call, recovery cardinality). Each now pins the env var explicitly so it tests its real subject, and beforeEach/afterEach isolate the variable so a stray value in a developer's environment cannot change what any of them assert.

Verification

bun run typecheck                                          # clean
bun test codex-catalog + registry-parity + zhipu + derive  # 164 pass, 0 fail
bun test windows-secret-acl                                # 157 pass, 0 fail

The full prepush gate (typecheck, frontend lint, full test suite, privacy scan) ran and passed on push. No frontend files are touched by this PR — git diff --name-only returns zero paths under that directory, so there is no UI change to screenshot.

Every new test was confirmed to fail with its production change reverted, then restored:

Reverted	Result
registry opt-ins + per-key merge	2 fail
destination fallback	1 fail
persistence guard	1 fail
ACL default back to 5s	1 fail

This work failed independent audit twice before passing. Both rounds are recorded in devlog/_plan/260807_untouched_bug_stack/020_routed_reasoning_effort.md, including the per-key regression I introduced in the fallback and then removed.

Checklist

Scope stays focused and avoids unrelated cleanup.
Docs or release notes were updated when needed.
Security-sensitive changes were reviewed for secrets, auth, and unsafe defaults.

Summary by CodeRabbit

New Features
- Added reasoning-summary support metadata for additional providers and models.
- Added support for the domestic BigModel Coding Plan endpoint.
- Improved metadata enrichment for custom provider names and vendor endpoints while preserving explicit settings.
Bug Fixes
- Prevented registry defaults from being saved as user overrides.
- Increased the default Windows ACL hardening timeout from 5 to 30 seconds.
Tests
- Expanded coverage for provider enrichment, reasoning support, endpoint behavior, and ACL timeout handling.

github-actions · 2026-08-07T08:07:54Z

✅ Deterministic PR hygiene checks passed.

coderabbitai · 2026-08-07T08:07:55Z

📝 Walkthrough

Walkthrough

The provider registry now carries per-model reasoning-summary metadata, supports routed enrichment for custom provider names, and adds a Zhipu Coding Plan entry. Catalog enrichment preserves user values. Windows ACL hardening now uses a 30-second default deadline. Tests cover these changes and SQLite contention filtering.

Changes

Provider reasoning-summary enrichment

Layer / File(s)	Summary
Registry metadata and provider routes `src/providers/registry.ts`, `tests/provider-registry-parity.test.ts`	Adds `modelSupportsReasoningSummaries` metadata, updates OpenCode Go, DeepSeek, and Z.AI Coding Plan entries, and adds the `zhipu-bigmodel-coding` route with parity expectations.
Routed provider enrichment `src/providers/derive.ts`, `src/oauth/key-providers.ts`	Merges per-model registry defaults without replacing explicit values. Custom provider names can use destination-based lookup. Catalog enrichment removes registry-only metadata before persistence.
Provider enrichment validation and audit `tests/codex-catalog.test.ts`, `devlog/_plan/260807_untouched_bug_stack/020_routed_reasoning_effort.md`	Tests reasoning ladders, endpoint fallback, override precedence, persistence behavior, and conservative opt-in handling. The audit records the fallback corrections and deferred endpoint work.

Windows ACL hardening deadline

Layer / File(s)	Summary
ACL deadline and timeout coverage `src/lib/windows-secret-acl.ts`, `tests/windows-secret-acl.test.ts`	Changes the default ACL deadline from 5 to 30 seconds. Tests isolate `OPENCODEX_ACL_TIMEOUT_MS` and cover slow successful steps, malformed values, timeout short-circuiting, and retries.

Retained-root serialization filtering

Layer / File(s)	Summary
SQLite contention exclusions `tests/codex-retained-root-serialization.test.ts`	Adds SQLite lock messages and `SQLITE_BUSY` to the pre-approval failure exclusions.

Estimated code review effort: 4 (Complex) | ~45 minutes

Sequence Diagram(s)

sequenceDiagram
  participant ProviderConfig
  participant enrichProviderFromCatalog
  participant enrichProviderFromRegistry
  participant ProviderRegistry
  ProviderConfig->>enrichProviderFromCatalog: provider configuration
  enrichProviderFromCatalog->>enrichProviderFromRegistry: provider for enrichment
  enrichProviderFromRegistry->>ProviderRegistry: provider name or destination lookup
  ProviderRegistry-->>enrichProviderFromRegistry: registry metadata
  enrichProviderFromRegistry-->>enrichProviderFromCatalog: merged provider values
  enrichProviderFromCatalog-->>ProviderConfig: persisted user-owned configuration

Possibly related PRs

lidge-jun/opencodex#406: Shares provider registry and enrichment changes in src/providers/derive.ts and src/providers/registry.ts.
lidge-jun/opencodex#407: Overlaps with provider catalog enrichment and routed registry lookup.
lidge-jun/opencodex#1119: Shares catalog tests for routed reasoning-summary metadata and explicit per-model overrides.

Suggested labels: enhancement

Suggested reviewers: ingwannu, wibias, luvs01

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly summarizes both main changes: routed reasoning-effort propagation and the Windows ACL timeout increase.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

📝 Generate docstrings

Create stacked PR
Commit on current branch

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch codex/260807-routed-reasoning-effort

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

Add model-scoped reasoning-summary capability defaults for the registry-backed DeepSeek V4 and evidence-backed GLM models so Codex keeps sending the selected reasoning object. Merge the registry map per key, with defaults spread first and user configuration second. This preserves an explicit false for one model without suppressing defaults for every other model, and creates a detached object instead of aliasing registry metadata. Cover the catalog contract, partial override behavior, conservative no-opt-in default, and red-green production ablation for #1100.

On a machine where icacls is slow — Defender real-time scanning, a roaming profile, a domain-controller round trip — a complete ACL sequence could not finish inside the 5-second envelope. The harden failed closed, the native-main owner published a permanent `unavailable`, and every native request returned 503 until the user restarted. One correction to the issue's framing: PR #1135's retry is not the problem. Owner-level recovery calls hardenSecret again and does receive a fresh deadline. The defect is that one complete sequence — `/grant:r`, `/inheritance:r`, `/remove:g`, plus the conditional `/findsid` verification — had only five seconds for all of it. Raises the default to 30s and keeps everything else: the 60s cap, the OPENCODEX_ACL_TIMEOUT_MS override, the clamp, and the shared-envelope structure. Independent per-command budgets were rejected: with /findsid fallbacks they multiply into the multi-minute startup stall the shared budget was introduced to prevent. The cost is stated in the source comment rather than hidden. Because loadConfig hardens three paths sequentially, the timeout-path worst case at load becomes ~90s, and the owner path ~60.25s. Both need icacls to be pathologically slow on every call; a healthy machine finishes in milliseconds. A slow start is recoverable, a permanent 503 is not, and the failure stays fail-closed either way. Four existing tests depended on the 5s default while actually asserting something else — envelope sharing, fresh-budget-on-second-call, recovery cardinality. Each now pins OPENCODEX_ACL_TIMEOUT_MS explicitly so it tests its real subject, and beforeEach/afterEach isolate the variable so a stray value in a developer's environment cannot change what any of them assert. The new test deliberately does not pin: it exercises the shipped default with 13s of slow-but-successful work. Confirmed to fail with the default reverted to 5s.

…ff disk (#1100) Audit found the first commit fixed the canonical provider ids but missed the shape the issue was actually reported against. REACHING CUSTOM PROVIDERS. `enrichProviderFromRegistry` matches on the provider NAME. The reporter's row is a hand-added provider literally called "GLM" pointing at a vendor endpoint we recognize. Routing worked, so the row looked healthy, but no registry id is called "GLM" — so every piece of registry metadata was skipped, the effort ladder was advertised with summaries left false, and Codex dropped the inbound reasoning object. Exactly the bug, on the exact configuration that was reported. On the name-lookup miss we now fall back to `registryEntryForProviderDestination`, which already answers "which vendor endpoint is this row talking to" and is restricted to fixed key destinations — no templated or overridable base URL can be claimed by it. Scope is deliberately one field: a custom row keeps its own identity for everything else. PER-KEY, EVERYWHERE. The fallback first bailed whenever the user had any map, which recreated the whole-record bug the per-key merge exists to prevent: one model's flag would have suppressed every sibling default. Both paths now share `applyReasoningSummaryDefaults`, so an explicit value — including `false` — wins for its own key and nothing else. NOT PERSISTED. `enrichProviderFromCatalog` feeds a config about to be written to disk. Writing today's registry defaults there would freeze them as the user's own overrides, so a later correction — learning a model's backend rejects summary delivery — would never reach anyone who created their provider first, and they would keep getting 400s with no way to know why. It now restores exactly what the caller submitted. Catalog gathering enriches a detached runtime clone, so the defaults still apply where they matter. KNOWN REMAINING GAP: the reporter's endpoint, open.bigmodel.cn/api/coding/paas/v4, is in no registry entry — only /api/paas/v4 is. Closing that route needs a new registry entry with its own id (glm/glm-cn are bound in FREE_PROVIDER_DIRECTORY), its own evidence-backed model set, and registry-parity updates. That is a provider addition, not a bug fix, so it stays out of this stack and is recorded in the plan unit instead. Each new test was confirmed to fail with its production change reverted.

…el coding endpoint The first implementation passed its tests and was still wrong about the reported configuration: enrichment matches on provider NAME, and the reporter's row is a hand-added provider called "GLM". Recording the failure mode because it generalizes — canonical-id tests were green against a configuration no user had. Also records why the BigModel coding endpoint is deferred rather than fixed here, with the safety analysis for adding it later.

…was actually reported on The destination fallback added here matched two GLM routes: Z.AI's coding plan and BigModel's pay-as-you-go `/api/paas/v4`. The configuration in the issue is neither. It is `https://open.bigmodel.cn/api/coding/paas/v4` — a third endpoint with no registry row — so the lookup found nothing, `modelSupportsReasoningSummaries` stayed unset, and Codex kept dropping the reasoning object. Effort still displayed as `-`. The test hid this. It was captioned "the reporter's actual shape" and used provider name "GLM" and model glm-5.2, both correct, but substituted Z.AI's host. It passed against a route that already worked while the reported one stayed broken. Found in pre-merge review, not by the suite. A prefix match on `open.bigmodel.cn` would have covered both endpoints in one line. It is also how a config pointed at one vendor route inherits another route's metadata, which is the failure the exact-endpoint rule exists to prevent — so this is a separate row. Two details that are not arbitrary. The id is not `glm-cn`, which the free-provider directory already binds to this same path; registering it here would let routedProviderConfig() canonicalize a saved `glm-cn` config onto our baseUrl. And the model list follows Z.AI's coding-plan set rather than the pay-as-you-go one, because this endpoint is the subscription product and glm-5.2 only exists on that side. Ablation: pointing the new row's baseUrl elsewhere makes the reproduction test red. Refs #1100

…g the product code The serialization test excluded two pre-approval race outcomes and treated everything else as a seam failure. A macOS CI run produced a third: `SQLiteError: database is locked` on stderr, which failed the build. That contradicts the runtime. `configGenerationFailureReason` classifies that exact message as "busy" rather than a database fault, and the storage and history paths do the same. So the product already treats it as ordinary contention while this test called it a defect. Found by a red CI run rather than by the suite, which is the part worth noting: the test enumerated the races it had seen instead of the races the code recognizes, so a third one was a matter of timing rather than of whether it could happen. The two-process seam itself is unchanged and still fails on a genuine convergence error.

coderabbitai

Actionable comments posted: 3

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@devlog/_plan/260807_untouched_bug_stack/020_routed_reasoning_effort.md`:
- Around line 136-153: Update the “Deferred: the reporter's exact endpoint”
section to reflect that registry.ts now includes the zhipu-bigmodel-coding entry
for https://open.bigmodel.cn/api/coding/paas/v4. Remove statements claiming the
endpoint lacks a registry entry or remains deferred, while preserving the
historical rationale where useful and documenting the implemented provider
outcome.

In `@src/providers/registry.ts`:
- Around line 1727-1732: Update the `zhipu-bigmodel-coding` registry entry to
set `preserveCustomDestination: true`, ensuring
`providerMatchesRegistryTransport()` validates its fixed adapter and endpoint
for existing providers with the same name. Keep the key-based authentication and
fixed base URL unchanged.

In `@tests/codex-retained-root-serialization.test.ts`:
- Around line 510-514: Update the preApproval classification in the test’s
nonzero-exit handling to also match raw “SQLITE_LOCKED” stderr, alongside the
existing SQLITE_BUSY check. Add a focused regression case in the same test suite
that supplies raw SQLITE_LOCKED output and verifies it is treated as expected
contention rather than a catalog-convergence failure.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

Push a commit to this branch (recommended)
Create a new PR with the fixes

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: b3833929-d62e-42a0-b885-2c0c89a8f0fe

📥 Commits

Reviewing files that changed from the base of the PR and between 22283ec and aca150b.

📒 Files selected for processing (9)

devlog/_plan/260807_untouched_bug_stack/020_routed_reasoning_effort.md
src/lib/windows-secret-acl.ts
src/oauth/key-providers.ts
src/providers/derive.ts
src/providers/registry.ts
tests/codex-catalog.test.ts
tests/codex-retained-root-serialization.test.ts
tests/provider-registry-parity.test.ts
tests/windows-secret-acl.test.ts

coderabbitai · 2026-08-07T17:18:35Z

+## Deferred: the reporter's exact endpoint
+
+`https://open.bigmodel.cn/api/coding/paas/v4` appears in no registry entry —
+only `/api/paas/v4` does, as `zhipu-bigmodel`. The coding path exists solely in
+`FREE_PROVIDER_DIRECTORY` as `glm-cn`.
+
+Closing that route needs a new registry entry, and the audit confirmed it would
+be safe with a distinct id (`glm` and `glm-cn` are both already bound, and
+reusing either would retarget an existing config's endpoint — the warning at
+`registry.ts:1668-1676`). It also needs `preserveCustomDestination: true`, its
+own evidence-backed model set rather than the pay-as-you-go GLM 4.6–5.1
+metadata, and updates to `EXPECTED_KEY_PROVIDER_IDS` in
+`tests/provider-registry-parity.test.ts`.
+
+That is a provider addition, not a bug fix. It stays out of this stack
+deliberately: the destination fallback already fixes every custom-named row on
+an endpoint we know, and mixing a new vendor entry into a bug-fix chain would
+expand the review surface past what a reviewer can check in one pass.


📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick win

Update the endpoint status in this audit record.

This section says that https://open.bigmodel.cn/api/coding/paas/v4 has no registry entry and remains deferred. src/providers/registry.ts now adds zhipu-bigmodel-coding for that exact endpoint.

Replace the deferred-state statements with the implemented outcome. Keep the original audit rationale if it is useful for history.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@devlog/_plan/260807_untouched_bug_stack/020_routed_reasoning_effort.md` around lines 136 - 153, Update the “Deferred: the reporter's exact endpoint” section to reflect that registry.ts now includes the zhipu-bigmodel-coding entry for https://open.bigmodel.cn/api/coding/paas/v4. Remove statements claiming the endpoint lacks a registry entry or remains deferred, while preserving the historical rationale where useful and documenting the implemented provider outcome.

coderabbitai · 2026-08-07T17:18:35Z

+    id: "zhipu-bigmodel-coding",
+    label: "Zhipu AI — BigModel Coding Plan",
+    baseUrl: "https://open.bigmodel.cn/api/coding/paas/v4",
+    adapter: "openai-chat",
+    authKind: "key",
+    dashboardUrl: "https://bigmodel.cn/console/usercenter/apikeys",


🎯 Functional Correctness | 🟠 Major | ⚡ Quick win

Preserve custom destinations for this new fixed-route provider.

preserveCustomDestination is absent. Therefore, providerMatchesRegistryTransport() does not verify the adapter and endpoint for an existing provider named zhipu-bigmodel-coding.

A custom provider with this name and another destination can receive Coding Plan models and reasoning-summary defaults. That can enable summary delivery for an upstream that rejects it.

Set preserveCustomDestination: true. This entry has a fixed key endpoint and no base-URL override.

Proposed fix

{ id: "zhipu-bigmodel-coding", label: "Zhipu AI — BigModel Coding Plan", baseUrl: "https://open.bigmodel.cn/api/coding/paas/v4", adapter: "openai-chat", authKind: "key", + preserveCustomDestination: true,

As per path instructions, flag provider/adapter contract drift in src/**.

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

id: "zhipu-bigmodel-coding",

label: "Zhipu AI — BigModel Coding Plan",

baseUrl: "https://open.bigmodel.cn/api/coding/paas/v4",

adapter: "openai-chat",

authKind: "key",

dashboardUrl: "https://bigmodel.cn/console/usercenter/apikeys",

id: "zhipu-bigmodel-coding",

label: "Zhipu AI — BigModel Coding Plan",

baseUrl: "https://open.bigmodel.cn/api/coding/paas/v4",

adapter: "openai-chat",

authKind: "key",

preserveCustomDestination: true,

dashboardUrl: "https://bigmodel.cn/console/usercenter/apikeys",

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@src/providers/registry.ts` around lines 1727 - 1732, Update the `zhipu-bigmodel-coding` registry entry to set `preserveCustomDestination: true`, ensuring `providerMatchesRegistryTransport()` validates its fixed adapter and endpoint for existing providers with the same name. Keep the key-based authentication and fixed base URL unchanged.

Source: Path instructions

coderabbitai · 2026-08-07T17:18:35Z

    if (result.exitCode !== 0) {
      const preApproval = result.stderr.includes("CONFIG_MUTATION_LOCK_UNAVAILABLE")
-        || (result.stderr.includes("EEXIST") && result.stderr.includes("createOwnership"));
+        || (result.stderr.includes("EEXIST") && result.stderr.includes("createOwnership"))
+        || /database (?:is|table is) locked/i.test(result.stderr)
+        || result.stderr.includes("SQLITE_BUSY");


🗄️ Data Integrity & Integration | 🟠 Major | ⚡ Quick win

Also exclude raw SQLITE_LOCKED contention.

src/codex/catalog-write-serialization.ts:83-90 classifies both SQLITE_BUSY and SQLITE_LOCKED as expected SQLite contention. This filter only checks SQLITE_BUSY and locked-message text. A raw SQLITE_LOCKED error without that message can therefore fail the test as a catalog-convergence error.

Add the missing code check and a focused regression case.

Suggested fix

|| /database (?:is|table is) locked/i.test(result.stderr) - || result.stderr.includes("SQLITE_BUSY"); + || result.stderr.includes("SQLITE_BUSY") + || result.stderr.includes("SQLITE_LOCKED");

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@tests/codex-retained-root-serialization.test.ts` around lines 510 - 514, Update the preApproval classification in the test’s nonzero-exit handling to also match raw “SQLITE_LOCKED” stderr, alongside the existing SQLITE_BUSY check. Add a focused regression case in the same test suite that supplies raw SQLITE_LOCKED output and verifies it is treated as expected contention rather than a catalog-convergence failure.

lidge-jun requested review from Ingwannu and Wibias as code owners August 7, 2026 08:07

github-actions Bot added the bug Something isn't working label Aug 7, 2026

lidge-jun mentioned this pull request Aug 7, 2026

fix(update): gate the npm cache before shutdown and stop persisting vendor output (replaces #557) #1207

Merged

3 tasks

lidge-jun force-pushed the codex/260807-routed-reasoning-effort branch from f179645 to 32b01c2 Compare August 7, 2026 10:56

lidge-jun force-pushed the codex/260807-sse-unspaced-data-fields branch from a495bd8 to 8662a09 Compare August 7, 2026 10:56

lidge-jun added 4 commits August 7, 2026 20:28

lidge-jun force-pushed the codex/260807-routed-reasoning-effort branch from 32b01c2 to 392179e Compare August 7, 2026 11:34

lidge-jun changed the base branch from codex/260807-sse-unspaced-data-fields to dev August 7, 2026 16:55

coderabbitai Bot reviewed Aug 7, 2026

View reviewed changes

lidge-jun merged commit cb00907 into dev Aug 7, 2026
24 checks passed

lidge-jun deleted the codex/260807-routed-reasoning-effort branch August 8, 2026 00:49

Navigation Menu

fix(codex,acl): routed reasoning-effort propagation (#1100) and a workable Windows ACL envelope (#1156) - #1197

fix(codex,acl): routed reasoning-effort propagation (#1100) and a workable Windows ACL envelope (#1156)#1197
lidge-jun merged 6 commits into
devfrom
codex/260807-routed-reasoning-effort

lidge-jun commented Aug 7, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

github-actions Bot commented Aug 7, 2026

Uh oh!

coderabbitai Bot commented Aug 7, 2026 •

edited

Loading

Walkthrough

Changes

Sequence Diagram(s)

Uh oh!

coderabbitai Bot left a comment

Uh oh!

coderabbitai Bot Aug 7, 2026

Uh oh!

coderabbitai Bot Aug 7, 2026

Uh oh!

coderabbitai Bot Aug 7, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

lidge-jun commented Aug 7, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

#1100 — reasoning effort never reaches routed DeepSeek and GLM

#1156 — Windows ACL harden envelope

Verification

Checklist

Summary by CodeRabbit

Uh oh!

github-actions Bot commented Aug 7, 2026

Uh oh!

coderabbitai Bot commented Aug 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Sequence Diagram(s)

Uh oh!

coderabbitai Bot left a comment

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Aug 7, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Aug 7, 2026

Choose a reason for hiding this comment

Uh oh!

coderabbitai Bot Aug 7, 2026

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

lidge-jun commented Aug 7, 2026 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Aug 7, 2026 •

edited

Loading