Skip to content

an account adopts a login the host staged - #4

Merged
gradyzhuo merged 1 commit into
mainfrom
feat/account-adopts-a-login
Sep 30, 2026
Merged

gradyzhuo merged 1 commit into
mainfrom
feat/account-adopts-a-login

Conversation

@gradyzhuo

Copy link
Copy Markdown
Member
func adoptLogin(from directory: URL) async throws   // on Account

The host runs the tool's login against a throwaway directory and hands that directory over. Everything after is the tool's.

Why the split falls there

Running an interactive login is the host's: it knows how to give a subprocess a terminal and a foreground process group, and the only tool-specific inputs — authLoginCommand and the config-dir variable — are already on the tool's own description. It needs no further knowledge to do it.

What it cannot know is what the tool then wrote. Which file holds a credential, or which entry in a platform keychain, how that entry is named, what else travels with it — none of that has ever been expressible as a path. So the host passes one and asks nothing more.

On Account rather than the tool, for the same reason as the others: the caller is holding the account the login is for.

The directory is a throwaway

Its lifetime is the host's and may end the moment the call returns, so a conformer copies rather than remembering where it was. A test deletes the directory afterwards and checks the login survived.

The failure worth legislating for

adoptLogin throws when no usable login was found.

Reported as done instead, it hands someone an account they believe works and will not discover otherwise until they try to use it.

Verified the tests catch it: a conformer that returns quietly rather than throwing fails immediately — and that lenient version is exactly what gets written by accident.

Verification

132 tests pass; -strict-concurrency=complete -warnings-as-errors is clean.

The pinned capability set gains tool/adoptLogin, which is what that test is for — adding a method means updating it, and that is where documenting the method gets remembered.

🤖 Generated with Claude Code

`adoptLogin(from:)` on `Account`. The host runs the tool's login against a
throwaway directory and hands that directory over; everything after is the tool's.

The split falls where the knowledge does. Running an interactive login is the
host's: it knows how to give a subprocess a terminal, and the only tool-specific
inputs — `authLoginCommand` and the config-dir variable — are already on the
tool's own description, so it needs no further knowledge to do it. What it cannot
know is what the tool then wrote. Which file holds a credential, or which entry
in a platform keychain, how that entry is named, and what travels with it, has
never been expressible as a path. So the host passes one and asks nothing more.

On `Account` rather than the tool, for the reason the others are: the caller is
holding the account the login is for.

The directory's lifetime is the host's and may end the moment the call returns, so
a conformer copies rather than remembering where it was. A test deletes the
directory afterwards and checks the login survived.

`adoptLogin` throws when no usable login was found. That is the failure worth
legislating for: reported as done, it hands someone an account they believe works
and will not discover otherwise until they try to use it. Verified the tests catch
it — a conformer that returns quietly instead of throwing fails immediately, and
that lenient version is exactly what someone writes by accident.

132 tests pass.
@gradyzhuo
gradyzhuo merged commit 9f5c8c7 into main Sep 30, 2026
2 checks passed
@gradyzhuo
gradyzhuo deleted the feat/account-adopts-a-login branch September 30, 2026 01:27
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.

1 participant