fix(cli): os package publish --install can use the environment you just switched to - #18268

Closes #18265

Clause-②: no — this diff adds an optional field to a local CLI credential file (CloudConfig in packages/cli/src/utils/cloud-config.ts) and a flag fallback. No new key reaches a published payload, and no contract accepts or refuses anything it did not before.

What was wrong

os environments switch — and os environments create --activate, the other writer — persisted activeEnvironmentId into ~/.objectstack/credentials.json only, the runtime credential store. os package publish reads ~/.objectstack/cloud.json — the cloud store — and never opened the other file. So the environment the CLI had just called active, and that os environments list marks with a ★ on the very next line, was invisible to the one command that installs into it:

os cloud login
os environments switch <env-id>       # ✓ Active environment: Dev
os package publish --install
# → `--install` requires `--env <id>`. Skipping auto-install.

# …and the path that does not even have a `switch` in it — the card's own
# scenario, "I created my own cloud dev environment, now publish to it":
os environments create --org $ORG --name Dev   # --activate is the default
os package publish --install
# → `--install` requires `--env <id>`. Skipping auto-install.

Why the obvious fix is the wrong one

Letting publish read credentials.json is not merely impure — it is wrong at runtime. The two files carry different servers: credentials.json's url falls back to http://localhost:3000 (utils/api-client.ts), cloud.json's default is https://cloud.objectos.ai (utils/cloud-config.ts), and the publish POSTs to the latter. An activeEnvironmentId read out of the runtime store therefore names an environment on a possibly different control plane, which the server resolves by bare id with no name or short-id rescue.

So the id now lives in cloud.json, next to the activeOrgId that is already there for the same kind of control-plane scope selector, and the url gate — not the file name — is the invariant. It lives in exactly one place, packages/cli/src/utils/active-environment.ts:

• os environments switch records the id in cloud.json when the control plane it just talked to is cloud.json's url, and keeps writing credentials.json unchanged.
• os environments create --activate (the default) records it through the same helper. It is the other writer of an active environment id and the first half of the flow this PR exists for, so fixing only switch would have left the most natural path refusing while reading like a fix. It is one call, not a second implementation: two copies of a url gate is how one of them stops gating. Its existing failure posture is untouched — creation succeeding while the activation or the record fails stays a warning, never an exit 1.
• os package publish's --env falls back to that value when neither the flag nor $OS_ENVIRONMENT_ID is present, and only when cloud.json's url is the plane being published to.
• A value written by an older CLI into credentials.json is migrated across once, and only when both files' urls agree.

Guards — three legs, each measured red-before / green-after

A guard that only pinned "a fallback exists" would go green on the wrong fix, which is the whole reason this card is not the one-liner it looks like. So the read side has two legs and the second is the real invariant; the write side has a third, for the second writer. Every leg restores from HEAD (the implementation was committed first) and proves the mutation reached disk before the run is read.

Leg A — remove the fallback

Mutation: delete the resolveCloudActiveEnvironmentId call in packages/cli/src/commands/package/publish.ts.

HEAD blob for packages/cli/src/commands/package/publish.ts: 09c3b3072467d8d26f05bd3877d291e87cc69b41
--- dirty lines BEFORE mutation: 1
anchor occurrences before mutation: 1
anchor occurrences after mutation:  0
injected marker occurrences:        1
--- dirty lines AFTER mutation: 2
--- on-disk hash now: 643257b2dcb66bc5175251d7e96094b526033640  (HEAD: 09c3b3072467d8d26f05bd3877d291e87cc69b41)
--- ABLATION-18265-A marker occurrences on disk: 1
=== RED LEG exit: 1
 Test Files  1 failed (1)
      Tests  3 failed | 6 passed (9)

 FAIL  test/publish-active-environment-store.test.ts > installs into the active cloud environment when --install carries no --env
AssertionError: expected undefined to be 'env_cloud_active'
 FAIL  test/publish-active-environment-store.test.ts > reads the CLOUD store, not the runtime store, even when both name this same server
AssertionError: expected undefined to be 'env_from_cloud_json'
 FAIL  test/publish-active-environment-store.test.ts > migrates a pre-existing runtime value into cloud.json once, only when the urls agree
AssertionError: expected undefined to be 'env_switched_before_upgrade'

--- restored; git diff HEAD is empty? []
--- dirty lines AFTER restore: 1
--- on-disk hash after restore: 09c3b3072467d8d26f05bd3877d291e87cc69b41  (HEAD: 09c3b3072467d8d26f05bd3877d291e87cc69b41)
=== GREEN LEG exit: 0
 Test Files  1 passed (1)
      Tests  9 passed (9)

Leg B — point the fallback at credentials.json (the tempting wrong fix)

Mutation: in packages/cli/src/utils/active-environment.ts, read readAuthConfig()'s activeEnvironmentId ahead of cloud.json's.

HEAD blob for packages/cli/src/utils/active-environment.ts: 2e9ec18e3cb8d12bc6c714152f5758b9f5c29e03
--- dirty lines BEFORE mutation: 1
anchor occurrences before mutation: 1
anchor occurrences after mutation:  1
injected marker occurrences:        1
--- dirty lines AFTER mutation: 2
--- on-disk hash now: 6c3def2ad6dae867a0f81c3e8dc79e398af05f54  (HEAD: 2e9ec18e3cb8d12bc6c714152f5758b9f5c29e03)
--- ABLATION-18265-B marker occurrences on disk: 1
=== RED LEG exit: 1
 Test Files  1 failed (1)
      Tests  3 failed | 6 passed (9)

 FAIL  test/publish-active-environment-store.test.ts > reads the CLOUD store, not the runtime store, even when both name this same server
AssertionError: expected 'env_from_credentials_json' to be 'env_from_cloud_json'
 FAIL  test/publish-active-environment-store.test.ts > refuses to install across control planes: an active environment recorded elsewhere is not used
AssertionError: expected 'env_on_other_plane' to be undefined
 FAIL  test/publish-active-environment-store.test.ts > migrates a pre-existing runtime value into cloud.json once, only when the urls agree
AssertionError: expected undefined to be 'env_switched_before_upgrade'

--- restored; git diff HEAD is empty? []
--- dirty lines AFTER restore: 1
--- on-disk hash after restore: 2e9ec18e3cb8d12bc6c714152f5758b9f5c29e03  (HEAD: 2e9ec18e3cb8d12bc6c714152f5758b9f5c29e03)
=== GREEN LEG exit: 0
 Test Files  1 passed (1)
      Tests  9 passed (9)

The asymmetry is the finding. Under leg B the first guard — "installs into the active cloud environment" — stays green: only the second case, which seeds both stores with different ids under the same url, can tell a correct fallback from the runtime-store one. expected 'env_from_credentials_json' to be 'env_from_cloud_json' is the line that refuses the wrong fix, and expected 'env_on_other_plane' to be undefined is the cross-plane leak the card describes, caught in the same leg.

Leg C — os environments create --activate stops recording for the cloud plane

Mutation: in packages/cli/src/commands/environments/create.ts, replace the recordCloudActiveEnvironmentId call with recordedForCloud = false — the runtime write stays, exactly as create behaved before this PR.

HEAD blob for packages/cli/src/commands/environments/create.ts: 8385130ed810b51292e54f7502f36fa75d2ff313
--- dirty lines BEFORE mutation: 1
anchor occurrences before mutation: 1
anchor occurrences after mutation:  0
injected marker occurrences:        1
--- dirty lines AFTER mutation: 2
--- on-disk hash now: b42e66f2fc6fb3b3b2b07bc962a83480e2bc8d1f  (HEAD: 8385130ed810b51292e54f7502f36fa75d2ff313)
--- ABLATION-18265-C marker occurrences on disk: 1
=== RED LEG exit: 1
 Test Files  1 failed (1)
      Tests  1 failed | 10 passed (11)

 FAIL  |unit| test/publish-active-environment-store.test.ts > os environments create --activate records the id for the cloud plane too > a freshly created environment is immediately a publish target, with no switch in between
AssertionError: create --activate recorded the new environment in the runtime store only, so the very next `os package publish --install` cannot see it. That is the same defect as the one this file guards on `switch`, one command over.: expected undefined to be 'env_created'

--- restored; git diff HEAD is empty? []
--- dirty lines AFTER restore: 1
--- on-disk hash after restore: 8385130ed810b51292e54f7502f36fa75d2ff313  (HEAD: 8385130ed810b51292e54f7502f36fa75d2ff313)
=== GREEN LEG exit: 0
 Test Files  1 passed (1)
      Tests  11 passed (11)

Leg C reds exactly one case, and that is the reading. It is the only leg the new create --activate case can distinguish, and legs A and B were re-measured after it was folded in rather than assumed: A now reds 4 cases (the new one included — it asserts the publish end to end) and B still reds the same 3 as before, with the new case staying green under B because both stores hold the same id there. So the "same url, different ids" case remains the only thing in the file that refuses the credentials.json fix; adding a second writer did not quietly make some other assertion carry that weight.

Gates

Also run, from dispatch-gates.mjs's derived family for these paths — every one exit 0:

check:nul-bytes · check:cross-package-test-inputs · check:test-source-alias · check:tier-file-adoption · check:type-check-coverage · check:type-check-debt · check:published-files · check:cli-test-child-env · check:docs-single-h1 · check-doc-frontmatter.mjs · check-closing-keyword-parity.mjs · check-docs-section-name.mjs · check-undeclared-dep-imports.mjs · docs-audit/check-affected-docs.mjs

The full @objectstack/cli suite is red on this machine, and it is red without this change

pnpm --filter @objectstack/cli test ran both tiers on the final head: 11 failed · 3384 passed over 256 files. Not one failure is in a file this diff touches, and each was controlled against an unmodified checkout rather than argued away.

The comparison that matters is the failing set, not the count — and after the second writer was folded in, that set shrank: src/commands/datasource/envelope-unwrap.test.ts and 4 of the 5 published-entry-node-env-source-reroute cases (all load-dependent timeouts) passed this time, and 11 previously skipped cases ran and passed. No file entered the set. The arithmetic closes exactly: 3367 + 11 recovered skips + 4 recovered timeouts + 2 new cases = 3384.

A detached worktree at origin/main (fd1247142a, installed and built the same way) reproduces them. The counts below are the earlier, larger run — the superset; the final run is those same files minus envelope-unwrap, with 4 of the 5 reroute cases recovered:

The targeted run of the file this card adds is green on its own: Test Files 1 passed · Tests 9 passed (9).

Declared deviation — the shared verify lock was never taken. scripts/pm/os-verify-lock.sh printed UNLOCKED (declared) · no usable flock on this host, so the shared verify lock was NEVER taken and NOTHING was serialized on every run above that went through it (build, typecheck, test). Nothing was serialized against parallel seats on this container.

Declared narrowing. This is the targeted local set. The repo-wide gate farm is CI's run: node scripts/pm/dispatch-gates.mjs --commands derives 94 commands for this change set, plus 48 artifact-roster families, 11 wide-population families and 6 path-scheduled CI jobs it explicitly marks NOT MEASURED locally.

Acceptance notes

• The card body was verified line by line against origin/main before anything was written, and every line held. cloud-config.ts:42 (activeOrgId), cloud-config.ts:30 (DEFAULT_CLOUD_URL), cloud-config.ts:50 (the path), auth-config.ts:40/:47, switch.ts:58, api-client.ts:68/:78, publish.ts:501 and publish.ts:661 are all exactly where and what the card says.
• One clause of the card was read toward "no regression" where it was ambiguous. "os environments switch writes to cloud.json … otherwise it keeps writing credentials.json" could be read as exclusive-or. It is implemented as additive: the runtime store is written exactly as before, and cloud.json is written as well when the planes agree. An exclusive-or reading would silently stop createApiClient from finding an active environment for the data / meta / environments families — the very families the card's Out-of-scope section says keep authenticating as the runtime identity.
• One condition was added beyond the card's wording, for the card's own reason. The publish-side fallback is gated on cloud.json's url being the control plane being POSTed to, not only on the value being present. Without it, OS_CLOUD_URL=http://localhost:4000 os package publish --install would send an id recorded for cloud.objectos.ai to a different plane — the exact failure the card rejects the credentials.json fix for. It costs nothing in the card's own scenario (login, switch and publish all on one plane) and is measured by the third test case.
• os environments switch's write to credentials.json became best-effort. It was an unguarded readAuthConfig(), which throws when the file does not exist — so a user who only ran os cloud login got an exit 1 after the server-side activation had already succeeded. The cloud write now happens first, the runtime write matches environments/create.ts's existing .catch(() => null) shape, and the command says so when neither store could record it.
• Not done, deliberately: whether the whole os environments family should move to the cloud identity. It authenticates from credentials.json / $OS_TOKEN today and changing that changes which token existing users send — the card puts it out of scope and it stays out.
• The second writer was folded in rather than left as a follow-up, on a maintainer decision. An earlier revision of this PR noted os environments create --activate (environments/create.ts) as the other writer of activeEnvironmentId and held it back because the card names switch. It is in now: on the day this ships, os environments create --org $ORG --name Dev --activate followed by os package publish --install is still the most natural path to the card's own scenario, and a half-fix that reads as a fix is worse than an obvious gap. The remedy is one call to the helper that already exists here, it adds no new verification surface, and leg C measures it.
• Two user-visible strings in package publish named only os environments switch as the source of the install target — the Installing into the active environment … step line and the --install refusal. With two writers they were half-true, so both name both writers now, as do the --env rows and the install-target prose on cli.mdx and publish-and-preview.mdx.

Generated by Claude Code