feat(cfg): add DISABLE_STARTUP_RECLAIM flag

[wj-e2b]

Introduce a Config.DisableStartupReclaim field, bound to the DISABLE_STARTUP_RECLAIM environment variable, used to gate the startup resource-reclaim routine.

[chatgpt-codex-connector]

Codex usage limits have been reached for code reviews. Please check with the admins of this repo to increase the limits by adding credits.
Credits must be used to enable repository wide code reviews.

[cursor]

PR Summary

Low Risk
Config-only addition with a unit test; default behavior unchanged when the env var is unset.

Overview
Adds orchestrator config DisableStartupReclaim, read from DISABLE_STARTUP_RECLAIM, so operators can turn off the startup resource-reclaim path when that behavior is wired in. A parse test confirms the env var maps to the field when set to true.

^{Reviewed by Cursor Bugbot for commit 013e9e2. Bugbot is set up for automated code reviews on this repo. Configure here.}

[gemini-code-assist]

Code Review

This pull request introduces the DisableStartupReclaim configuration option and a corresponding unit test to verify it can be enabled. No issues or feedback were identified.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

📢 Thoughts on this report? Let us know!

[claude]

🔴 The new DisableStartupReclaim field (env DISABLE_STARTUP_RECLAIM) is declared at packages/orchestrator/pkg/cfg/model.go:84 but never read anywhere in the repo — a grep for DisableStartupReclaim / DISABLE_STARTUP_RECLAIM matches only the declaration and the new env-parsing test. The PR description says the field "is used to gate the startup resource-reclaim routine," but no startup-reclaim routine exists and no code consults Config.DisableStartupReclaim, so setting DISABLE_STARTUP_RECLAIM=true is a silent no-op. Either land the consumer in this PR or note in the description that the flag is currently inert pending a follow-up.

Extended reasoning...

What the bug is\n\nThis PR adds Config.DisableStartupReclaim bound to DISABLE_STARTUP_RECLAIM at packages/orchestrator/pkg/cfg/model.go:84, plus a test at packages/orchestrator/pkg/cfg/model_test.go:83-89 that only verifies the env tag parses. The PR description claims the field "is used to gate the startup resource-reclaim routine" (present tense), but no consumer of the field is present in this PR or in the post-merge tree.\n\nEvidence (repo-wide grep)\n\nA repo-wide search for both identifiers returns only three lines — all in this PR:\n\n\npackages/orchestrator/pkg/cfg/model.go:84: DisableStartupReclaim bool `env:"DISABLE_STARTUP_RECLAIM"`\npackages/orchestrator/pkg/cfg/model_test.go:84: t.Setenv("DISABLE_STARTUP_RECLAIM", "true")\npackages/orchestrator/pkg/cfg/model_test.go:88: assert.True(t, config.DisableStartupReclaim)\n\n\nNo c.DisableStartupReclaim read exists anywhere. Searching for any "startup reclaim" routine also turns up nothing. The only reclaim machinery in packages/orchestrator is sandbox.bestEffortReclaim (pkg/sandbox/reclaim.go:83), invoked per-sandbox during pause/snapshot from pkg/sandbox/sandbox.go:1195, and it is gated by a LaunchDarkly feature flag (featureflags.GetReclaimConfig) — not by anything in Config. The cmd/resume-build CLI exposes its own --reclaim flag.Bool, again unrelated to this Config field. There is no startup-time reclaim path that this knob could plausibly gate.\n\nContrast with sibling field\n\nThe adjacent Config.ForceStop field is consumed in packages/orchestrator/pkg/factories/run.go (and surfaced in the job template HCL). DisableStartupReclaim has no analogous consumer in either code or IaC.\n\nStep-by-step proof of the no-op\n\n1. Operator sets DISABLE_STARTUP_RECLAIM=true expecting to skip a startup reclaim pass, as the PR title and description advertise.\n2. Orchestrator boots. cfg.Parse() runs and config.DisableStartupReclaim is correctly parsed to true — the new test confirms only this.\n3. The orchestrator proceeds with the rest of startup. No code path reads config.DisableStartupReclaim, so nothing is skipped, suppressed, or otherwise altered.\n4. Net effect: behavior is identical to the DISABLE_STARTUP_RECLAIM unset case. The operator gets no warning that their flag did nothing.\n\nImpact\n\nShipping an advertised operator-facing switch that silently no-ops is a footgun: anyone who flips it expecting the documented behavior will be misled. The test also gives a false sense of coverage — it only checks the tautology that env parsing works, not that any routine is actually gated.\n\nHow to fix\n\nEither (a) include the consumer that reads config.DisableStartupReclaim (and the startup reclaim routine it gates) in this PR, or (b) explicitly note in the PR description / a code comment that the flag is currently inert and is being landed ahead of a follow-up. Option (b) is acceptable as prep, but the present-tense claim in the description should be softened to match reality.\n\nAddressing the duplicate-refutation\n\nOne verifier refuted bug_004 as a duplicate of bug_001. That refutation is correct in the sense that the two reports describe the same defect — and the synthesis layer has already merged them into a single finding (this one). The merged report carries forward the strongest framing from both: the dead-config observation, the absence of any startup-reclaim routine to gate, and the ForceStop counter-example from bug_004. No double-reporting occurs — this is a single comment about a single field.