teaBinary hardcoded ~/.local/bin:$PATH. Right for tea, wrong as a habit: iris wrote the same function
with ~/.cargo/bin added, the two disagreed, and a rustup-only machine was refused a plugin its own
sidecar could build.
locateBinary asks the owner's login shell, so it knows about every directory a per-user installer
added without anyone listing them. Verified it still resolves tea from ~/.local/bin, which is the case
the comment above it was written for.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
It read /home/<osUser>, which is not where an Officer member's home is. Theirs
is DATA_PATH/<email>/home — where provisionUserDirs puts it and what useradd
was given — so a member with a working tea login was told they had none, and
the settings page asked for a token they had already set.
osUserHome is the platform's own answer to that question, and the same one tea
itself gets when run as that account, so reading and running now agree about
the path.
Not a sudo problem: runAs was escalating correctly the whole time, into a
directory that does not exist on any install.
The form asked for a URL and a token together, on a fresh instance, while the
machine in front of it often had both on disk already — somebody had run `tea
login` by hand.
Two changes.
One thing at a time: until the platform knows where Gitea is, a token cannot be
checked, because there is nothing to check it against. So the owner names the
instance first, and only then does the page ask for — or discover — a token.
That step now probes /api/v1/version unauthenticated, since demanding a token
to validate a URL refuses a good URL for the wrong reason and sends whoever
typed it looking for a credential problem.
And it reads tea's own config when the platform has no instance yet, offering
the URL it finds. A machine that already has a working login should not be
asked to retype what it can see.
Members skip the first step entirely — the instance is the owner's.
PM2 hands the sidecar a login-less PATH that excludes ~/.local/bin, which is
exactly where the platform installs a release binary. So `tea whoami` failed
with "the token may be wrong, or tea is not installed" on a machine where tea
was sitting in the owner's home and working perfectly from a shell.
Third time today the same trap: the probe in os-deps, then the agent's env, now
this. Anything the platform installs to ~/.local/bin has to be found
deliberately, because nothing the platform spawns inherits a PATH that includes
it.
Resolved per call rather than cached, so an install that adds it mid-run is
picked up instead of a cached "missing" outliving the thing that fixed it.
It was stored encrypted in service_connections as well. Nothing needs it there
any more: the UI is an iframe carrying the browser's own Gitea session, so the
only consumer left was the health probe. Meanwhile tea keeps its own copy
regardless — it is what the agent uses, and what this plugin's affordance tells
the agent to use.
Two copies of one secret is a drift waiting to happen: rotate with `tea login`
and the database quietly keeps the dead one. So the token lives once, where it
is used, and saving now writes `tea login add --name officer` AS that account —
a member's token lands in a home only they can read. `secret: null` on save
clears whatever an earlier version stored, so an upgraded machine stops
carrying a copy nothing reads.
service_connections keeps the URL, which is the owner's and genuinely shared.
The settings page READS the existing config first, so on a machine where the
owner and their members already ran `tea login` by hand it says "tea is
configured as X" rather than demanding something they have. It also says when
an account has no OS user yet, since there is then nowhere to write one — the
web view works regardless.
Test runs `tea whoami` as that account. Deliberately not a call the platform
makes with a token it read: the point is to prove what the AGENT will get, and
those are now the same thing. `--name officer` so the platform never overwrites
a login somebody set up by hand.
Noted rather than hidden: `tea login add` takes the token in argv, visible in
ps while it runs. tea offers no stdin form, and the alternative is writing its
YAML by hand — a visible argument traded for a fragile format.
pastilhasandClaude Opus 5