[immakermatty]

Why

Decision of the Principal on 2026-09-28: there are three kinds of Environment (Personal, Work, Work Team), and a Team Environment works out of the box with the Organization's bot, the GitHub App "Lazurio for GitHub". A person's GitHub account is not signed in there and a person's SSH key is not linked. The earlier temporary exception for Team Machines ends.

The Launchpad already hid the gh actions on a Team Environment (#60), but the server and the CLI enforced nothing, and on a Machine with the Organization's broker the product showed gh as "Not signed in" although gh works.

What changes

• One rule in one place (src/tools/team-github.ts): on the preset hosted-organization-team the sign-in of gh and the linking of an SSH key are refused; sign-out is allowed only when gh's active account is a person's stored sign-in. The CLI, the routes and the page use the same function.
• Refusal as a result, not an error: {kind: "blocked", reason: "team-environment", …}, exit 2 in the CLI, HTTP 409 from the server, with one wording in Czech and English.
• A personal account left on a Team Environment can be signed out, including the removal of the key Lazurio registered. The Organization's bot or a token from a variable is never signed out.
• The broker's gh reads as what it is. The probe asks gh auth status --json hosts first (gh 2.81.0 and newer; the only gh auth command the broker's wrapper answers) and falls back to the text form for an older gh. The Team row says "Works as lazurio-for-github[bot] · Uses Lazurio for GitHub". The token is never requested (--show-token is never passed) and never reaches a result.
• The prompt and the installation on a Team Environment no longer lead to a sign-in: lazurio tools prompt gh prints a Team prompt, lazurio tools install gh ends with the Team sentence, the page offers "Install" and not "Install and sign in".
• composio and wacli stay allowed on a Team Environment, with the shared sign-ins warning (now also in the CLI).

How a command learns the kind of Environment

The Launchpad server reads the preset of its own Folder on every gated request. tools login, logout, install and prompt take no Folder; on a hosted Machine they read the preset of the operator's Folder the way lazurio update finds it. Without such a Folder (a workstation) they behave as before.

What does not change

Generated Folder instructions and the template revision. The two other hosted presets and the local Folder. The path through Lazurio for GitHub itself is delivered by the Machine; the Platform does not build it.

Known limits, stated plainly

• A personal account stored behind an active broker token is not the active account and is not signed out by this rule.
• When the hosted Folder cannot be read, the CLI behaves as on a workstation and allows a sign-in; the Launchpad fails closed in that case.
• The wrapper's behaviour comes from reading its source and reproducing it in the fake gh. The real wrapper on a Team Machine is not qualified yet.

Verification

bun run check by the implementing agent on this head: 765 pass, 4 skip, 0 fail; public guard and standalone smoke pass. Fake tools, temporary HOME, a PATH without system directories. The delegating agent read the rule and the texts and did not re-run the check locally; the required checks on GitHub run it on both systems.

Refs #57

🤖 Generated with Claude Code

Update 2026-09-28 (head e22a858): the flaky gh login test

Pablo's second review found the gh login test failing when tests/launchpad-curated.test.ts ran together with tests/update-path-entry.test.ts (and macOS CI red). Root cause, reproduced locally (about 1 in 6 runs of the pair): not shared test state but a race this PR introduced — the poll route's Team-rule check and the running gh session's re-check both read the Folder's preset under the Folder operation lock, which is exclusive and non-blocking (flock LOCK_EX|LOCK_NB), so under load one read was refused as busy and the poll answered operation-failed.

Fix: reads (folderPreset, tools status, readFolderTools, /api/profile) go through withFolderReadLock, which retries only on the new FolderOperationBusyError for at most 3 s with a ≤100 ms backoff; mutations keep the immediate refusal and the lock messages are unchanged. Regression tests: 24 parallel preset reads, a read waiting for a holder, the 3 s bound, and a full Launchpad gh login completing while another reader keeps taking the lock (the pair passed 16/16 in both orders afterwards). Author's own bun run check on e22a858: lint, typecheck, all tests, check:public, build:proof, smoke:proof green (exit 0).

[agentrozjedemeai]

Blocking (exact head 8ea9ad1): an already-running gh device flow survives a Folder transition to hosted-organization-team. src/launchpad/server.ts:397-445 guards start and poll, but /api/update changes the preset without cancelling the in-memory session; src/tools/login.ts:577-607 continues the subprocess and, after device approval, writes a personal gh sign-in and proceeds to SSH key linking without another preset gate. A holder need not poll. I reproduced this in an isolated fixture: start gh under hosted-organization-personal, call updateProfile to hosted-organization-team, observe the new refusal, approve the fake gh flow without polling, and observe gh.state=octocat while the recorded preset remains hosted-organization-team. Please cancel pending gh sessions on transition to Team and/or recheck the current preset before completion and before SSH key effects, with a regression that does not poll after the switch. No real account or key was touched. The two required Platform checks (ubuntu-24.04 and macos-14) passed on this exact head; the optional Macroscope check was skipped. Focused local tests: 48 passed; this additional no-poll reproduction passed.

[agentrozjedemeai]

@immakermatty Exact-head re-review of 8d950e0: the prior Work-to-Team no-poll sign-in/key finding is addressed by the new checkpoints and the /api/update cancellation; the focused transition tests pass. I cannot approve while the required macOS check is red on this very commit (run 36421377210, job 108924664991; Ubuntu passes, Macroscope skipped). The macOS job fails at tests/launchpad-curated.test.ts:269: expected signed-in/SSH linked, got failed/environment-unreadable. In a fresh detached clone of this SHA with Bun 1.4.2 and host-wide heavy.lock, bun test tests/launchpad-curated.test.ts tests/update-path-entry.test.ts reproduces a failure of the same gh test twice (the response is operation-failed/recoveryMayBeRequired); bun test tests/launchpad-curated.test.ts alone passes. These are distinct observed failure results, not a proven shared root cause, but the multi-file check is not green even without concurrent host workloads. Please isolate and fix the cross-file interaction or make the gh flow deterministic, then rerun both required checks on the replacement exact head. No real account or SSH key was touched. Review only; no merge.

[agentrozjedemeai]

@immakermatty Exact-head re-review of e22a858: the prior cross-file failure is addressed by bounded retry of Folder read-lock contention. The read path retries only FolderOperationBusyError for at most 3 s; mutation paths still use the immediate-refusal operation lock. In a fresh isolated clone on Bun 1.4.2, the reproduction pair (launchpad-curated + update-path-entry) passed 3/3 in each order (13 pass, 0 fail each run); the focused tools-team-github/tools-login/launchpad-tools suite passed 52/52, including contention, bounded-read and mutation-refusal tests. git diff --check passed. Both required Platform checks on this SHA passed (Ubuntu and macOS; optional Macroscope skipped). No real account/key touched. Review only; do not merge.

[agentrozjedemeai]

@immakermatty Exact-head re-review of fc9d94d. The merge has parents e22a858 and main c624e73. Compared with e22a858, the five changed files are precisely the c624e73 main patch (identical stable patch-id); there is no additional PR-specific edit. In a fresh detached clone on Bun 1.4.2, lint and typecheck passed, and tools-team-github, launchpad-curated and update-path-entry passed together (34 pass, 0 fail). git diff --check passed. Both required Platform checks are SUCCESS on fc9d94d (Ubuntu and macOS); optional Macroscope is skipped. No unresolved conversations or pending review requests; base is current main and merge state is CLEAN. This renews the prior substantive approval on the merged exact head. Review only; do not merge.