Skip to content

devguard: pin DevGuard at 6e7e065 for its credential read fix - #89

Merged
novelKR merged 1 commit into
mainfrom
claude/project-thread-af6ntg
Oct 8, 2026
Merged

novelKR merged 1 commit into
mainfrom
claude/project-thread-af6ntg

Conversation

@novelKR

@novelKR novelKR commented Oct 8, 2026 •

Copy link
Copy Markdown
Owner

Requested by Seongjae · project thread

Issue

No CodeSpace issue. This picks up the fix for novelKR/DevGuard#24, merged as novelKR/DevGuard#27, and with it the credential deadline that #84 recorded under "Observed, not changed here".

Summary

Before: CodeSpace linked DevGuard's client at f1f9084. Its credential reader gives a consumer secret 250 ms of wall time and fails as soon as that has passed, before it looks at the descriptor again. A thread that the scheduler held that long got credential_unavailable although the credential file was intact or the handed descriptor already held the whole secret. For the gateway's status probes and in-process registration, that cost one session. The UDS worker reads its handed secret once, at start, so a stall there left it reporting credential_unavailable until it was restarted.

After: CodeSpace links DevGuard's client at 6e7e065, DevGuard main after novelKR/DevGuard#27. Once the deadline has passed, the reader still takes a secret and EOF that are already readable, and it fails on the first pass that finds nothing. CodeSpace's credential file is a regular file, and the gateway closes the handoff's writing end before the worker starts, so on both paths a reader delayed past the deadline still gets the secret. A writer that never writes or never closes still fails at the deadline.

How: the pin changes in one commit, as docs/upstream-lock.md requires:

  • crates/devguard/Cargo.toml: the rev of devguard-client, devguard-contract and the dev-only devguard-daemon.
  • Cargo.lock, crates/devguard/Cargo.lock and crates/codex-runtime/Cargo.lock, regenerated by Cargo (cargo metadata without --locked, which re-resolves only the changed source). Only the source lines of the DevGuard packages change (2, 5 and 2 lines). No package, version or checksum is added, removed or changed.
  • scripts/upstream_dependencies.py (DEVGUARD_SOURCE), and scripts/tests/test_upstream.py, whose moved-source case now replaces the new commit's prefix.
  • docs/upstream-lock.md (the pin record) and the status line of docs/devguard-integration.md. The Korean counterparts were reviewed, and both pairs' hashes recorded with scripts/check_docs.py record.

Between the two commits, DevGuard's code differs only in crates/client/src/credential.rs (+57/−13). DevGuard's other 19 changed files are its documentation and milestone ledger. The client's public API is unchanged.

Contract changes

None. No tool schema, error code, status value, ID, setting or wire protocol changes (the runner protocol stays 7). credential_unavailable keeps its meaning. It is no longer reported for a usable credential whose reader was delayed.

Tests

These were verified in a Linux x86_64 container at 6fe91e7, with Rust 1.97.0 and CARGO_INCREMENTAL=0 and CARGO_PROFILE_DEV_DEBUG=0 as in CI. The command was python3 scripts/validate-upstream.py pin policy python format dependencies unit-devguard clippy-adapters clippy-root clippy-codex unit-codex-runtime integration, and every stage passed:

  • pin, policy and format passed; format covers the root and every adapter workspace. python: 54 tests passed, including test_devguard_and_codex_each_have_one_source with the new source.
  • dependencies: no product graph has a violation. Compared with the base's graphs at d543ea5, three graphs differ: root+devguard, codex-runtime+devguard and devguard. Each differs in exactly 2 packages (devguard-client, devguard-contract) and 9 edges, and only by the DevGuard commit in their source. Every other graph is identical.
  • unit-devguard: 32 passed. The 3 ignored tests are child processes that their parent tests run. On Linux the fixture authority has no native host evidence, so the adapter's native registration and admission tests run only on the macOS leg.
  • Clippy reported no warnings in any stage:
    • clippy-adapters.
    • clippy-root, including codespace-server, codespace-runner and codespace-domain with --features devguard.
    • clippy-codex, covering the worker with and without devguard.
  • unit-codex-runtime: lib 1 and runtime_binary 6 passed. With --features devguard --bin codespace-codex-runtime, 1 passed.
  • integration: every suite passed in each command:
    • cargo test --locked --workspace: runner lib 102 passed, server lib 30 passed.
    • -p codespace-server --features devguard: lib 56 passed. The 5 ignored tests are child processes that their parent tests run.
    • -p codespace-runner --features devguard --lib: 122 passed.
    • -p codespace-domain --features devguard --lib: 32 passed.
  • python3 -B scripts/check_docs.py: 17 paired documents verified.

Not verified here:

  • The macOS legs, including the native DevGuard tests of the adapter, the runner and the gateway.
  • linux-isolation, because this container has no bubblewrap.
  • The unit tests of the adapters that do not link DevGuard.
  • The docs-site build.

All of them run in this PR's CI, whose plan is full.

Security scenarios

  • In every product graph, the dependency check accepts each devguard-* package only from 6e7e065. It still admits only devguard-client and devguard-contract to a product graph, so DevGuard's fixtures stay development dependencies.
  • The reader keeps its bounds: the 64-byte secret, the 65-byte read bound, and close-on-exec. It consumes and closes the descriptor on success and on every error. Past the deadline it never waits: poll uses a zero timeout and a pass without progress fails, so a writer that holds the descriptor open still fails at 250 ms.
  • Where the secret goes is unchanged: never in a flag, the environment, MCP input or output, a log or a status.

Out of scope

  • The tests that run a session again when it stops at the credential deadline are unchanged, as are the comments that explain them. They are past_the_credential in the adapter's and gateway's tests, and the runner's registration tests that ask again. With this pin, a usable credential should no longer stop a session, so the retries should no longer be taken. This is inferred from the fix, not measured. Removing them is a separate change.
  • DevGuard's 250 ms frame deadlines are unchanged by design.
  • The installed DevGuard keeps its own reader until a new DevGuard release. That includes the launch helper's permit read, which CS-RG U4 will use. The qualified release is 0.1.0-5daee5d-b3fa569e, and a new release is a separate decision.
  • The Codex pin 6b9826e is unchanged. This PR does no CS-RG unit work.

DevGuard main 6e7e065 (DevGuard PR #27) fixes DevGuard#24: once the
client's 250 ms credential read deadline has passed, it still takes a
secret and EOF that are already readable instead of failing. Its code
differs from f1f9084 only in crates/client/src/credential.rs.

As docs/upstream-lock.md requires, the adapter manifest, the root,
adapter and worker lockfiles, DEVGUARD_SOURCE and its test, and the pin
record change together. Cargo regenerated the lockfiles; only their
DevGuard source lines change. The status line of
docs/devguard-integration.md names the new commit; the Korean
counterparts are updated and both pairs' hashes recorded.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
@novelKR novelKR self-assigned this Oct 8, 2026
@novelKR
novelKR merged commit e0610c4 into main Oct 8, 2026
19 checks passed
novelKR pushed a commit to novelKR/DevGuard that referenced this pull request Oct 8, 2026
The owner directed CSRG-U4 to start on 2026-10-08, after CSRG-U3 merged in
CodeSpace as novelKR/CodeSpace#88 (d543ea5) and CodeSpace moved its DevGuard
pin to 6e7e065 as novelKR/CodeSpace#89 (e0610c4), both with their post-merge
CI green. Record U4 as active with the units dated 2026-10-08, keep U5 and U6
not started, and say so in AGENTS.md, the milestone table and note, the
planning index and the CS-RG plan, English and Korean. CS-RG stays
in-progress with qualification not-run, and the suspension of the
CSRG-C00-C09 plan is unchanged. Korean counterparts reviewed;
planning-readme and planning-milestones-cs-rg hashes recorded.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants