devcontainer: settle whether Claude OAuth refresh rotates single-use — one credential copied into N parallel containers #259

New issue

Open

opened 2026-08-26 11:46:58 +00:00 by jbr870 · 0 comments

jbr870 commented

2026-08-26 11:46:58 +00:00

Owner

Spawned from finding F-PO-61-3-1 (in-scope-deferrable, severity high) on issue #61 during decision D-PO-61-3-1.

Original scope note: Run 5 lost seven criteria to Failed to authenticate: OAuth session expired and could not be refreshed inside containers, while the host credential remained valid. Run 6 then passed 23/23 with 240 credential samples showing no rotation at all — but the access token was ~7h50m from expiry throughout, so no container ever needed to refresh. Run 6 therefore avoided the rotation path rather than clearing it.

What is established: ~28 containers holding copies of a valid credential work concurrently, which was never in doubt.
What is not established: what happens when the token expires with N copies live — precisely run 5's scenario, and precisely what D-PO-61-2-3's waiver deferred. That waiver's own tripwire reads: revisit BEFORE relying on unattended parallel runs. Unattended parallel operation is #61's stated purpose, so this is the gap between the feature shipping and the feature delivering.

Disposition rationale: Settling it needs a deliberate experiment, not a code change: bring a credential close to expiry, run several containers holding copies, and observe whether one container's refresh invalidates its siblings (single-use refresh-token rotation) or leaves them working. Bounded work with a clear result, but not #61's build.

What the answer decides:

Rotation is not single-use → the copied-credential design stands; document the finding and close.
Rotation is single-use → the copied-credential design is not viable at N>1. Per-container Claude logins — rejected at requirements time on setup-ceremony grounds — come back on the table, which is a requirements conversation rather than a fix. See also F#9 / D-PO-61-2-4 on #61.

Mitigation available today (attended use only): the failure is loud, and dw.sh refresh-creds <N> recovers a container in one command. That is not a mitigation for unattended runs, where the same failure is silent until the run is found dead.

This issue was deferred out of the parent feature's scope; it carries no PREQ yet. Run /dev:requirements --issue={this} to flesh it out before planning.

Spawned from finding `F-PO-61-3-1` (in-scope-deferrable, severity high) on issue #61 during decision `D-PO-61-3-1`. **Original scope note:** Run 5 lost seven criteria to `Failed to authenticate: OAuth session expired and could not be refreshed` inside containers, while the host credential remained valid. Run 6 then passed 23/23 with 240 credential samples showing no rotation at all — but the access token was ~7h50m from expiry throughout, so no container ever *needed* to refresh. Run 6 therefore avoided the rotation path rather than clearing it. What is established: ~28 containers holding copies of a **valid** credential work concurrently, which was never in doubt. What is **not** established: what happens when the token expires with N copies live — precisely run 5's scenario, and precisely what `D-PO-61-2-3`'s waiver deferred. That waiver's own tripwire reads: *revisit BEFORE relying on unattended parallel runs.* Unattended parallel operation is #61's stated purpose, so this is the gap between the feature shipping and the feature delivering. **Disposition rationale:** Settling it needs a deliberate experiment, not a code change: bring a credential close to expiry, run several containers holding copies, and observe whether one container's refresh invalidates its siblings (single-use refresh-token rotation) or leaves them working. Bounded work with a clear result, but not #61's build. **What the answer decides:** - **Rotation is not single-use** → the copied-credential design stands; document the finding and close. - **Rotation is single-use** → the copied-credential design is not viable at N>1. Per-container Claude logins — rejected at requirements time on setup-ceremony grounds — come back on the table, which is a requirements conversation rather than a fix. See also `F#9` / `D-PO-61-2-4` on #61. **Mitigation available today (attended use only):** the failure is loud, and `dw.sh refresh-creds <N>` recovers a container in one command. That is not a mitigation for unattended runs, where the same failure is silent until the run is found dead. This issue was deferred out of the parent feature's scope; it carries no PREQ yet. Run `/dev:requirements --issue={this}` to flesh it out before planning.

jbr870 added the

labels

2026-08-26 11:46:58 +00:00

jbr870 referenced this issue

2026-08-26 11:47:09 +00:00

devcontainer: refresh for the plugin era — per-container claude state, worktree plugin wiring, parallel-safe compose naming #61

jbr870 referenced this issue

2026-08-26 14:38:49 +00:00