Repository navigation
Login runs the recipe's bare command from PATH, not the agent patchbay launched #93
Description
Problem
An agent's Log in can run a different binary from the one patchbay connected to. OpenCode shows it on both of its current versions (wire-checked 2026-10-08 with patchbay's own initialize):
opencode-login method |
what patchbay runs | |
|---|---|---|
| 1.18.35 (registry) | no type, plus _meta["terminal-auth"] {command: "opencode", args: ["auth","login"]} |
bare opencode auth login, resolved from PATH |
2.0.25 (@opencode/cli) |
type: "terminal", args: ["--login"], and the same _meta recipe |
the same bare opencode auth login |
Patchbay starts the agent from an absolute path: the staged registry binary, or a custom command such as C:\…\opencode.exe acp. The login doesn't use that path. It uses whatever opencode the PATH finds:
- Registry install, nothing on PATH: the command isn't found and the login fails.
- PATH points at another install (v1 next to a custom v2, or the desktop app that takes the
opencodename on some installs): credentials go to that install, not to the agent the card shows.
Reported live on anomalyco/opencode#11176: a user's local v2 opencode.exe added through Add custom.
Root cause
readAuthMethods (readers/initialize.ts) lets a parseable _meta recipe win over the method's own type. That rule was made for Auggie, which ships its recipe on a type-less method whose authenticate does nothing. Recipe-first is still right there. But it also overrides a spec terminal method when one exists. That spec path (typedLoginViaTerminal) runs the agent's own spawn spec plus the method's args, with the agent's env and the Windows resolver — the right binary by construction.
When there's no typed method (1.18.35), the recipe is the only path, and its command is a bare name. The recipe convention expects a machine-absolute command, and OpenCode sends a name.
Decision needed
- A spec
terminalmethod and a_metarecipe, both parseable — which runs? Proposal: the typed method. It's the spec path, and the recipe remains the fallback for type-less methods (Auggie unchanged). This fixes 2.0.25. - A recipe whose
commandis a bare name — what resolves it? Options: run it as the agent wrote it (today), or put the agent's own executable directory first on the login task's PATH so the bare name finds the binary patchbay launched (shape-based, no vendor named). This decides 1.18.35.
Activity
hussain commentedon Oct 8, 2026
Decision, after measuring every agent's
authMethodsagainst each client declaration (spec only /_metaonly / both):A method with no
typethat carries a_meta["terminal-auth"]recipe is the convention from before the spec had terminal methods. OpenCode 2.0.25 sends exactly that shape to a_meta-only client, and the typed method to a spec client. A method carrying both is one login, sent for both kinds of client. Patchbay declares both, so the typed method is the one meant for it.Login, per method:
type: "terminal"→ the spec path: the agent's configured launch + the method'sargs, itsenvover the agent's. A recipe on the same method is ignored. (Claude, OpenCode 2.x)env. (Auggie, OpenCode 1.x)agent→authenticate. (Codex)A recipe's bare
commandstays as written: the convention asks for a path on the user's machine, and that is the agent's to send. OpenCode 1.x gets a note upstream.fix(auth): a typed terminal login runs the agent you launched
hussain commentedon Oct 8, 2026
Fixed in 9986ad6 — ships with 0.84.3.
A spec
terminalmethod now wins over a_meta["terminal-auth"]recipe sent beside it: Log in runs the agent's own launch with the method's arguments — for OpenCode 2.x,<the binary Patchbay launched> acp --login. A recipe still runs where it is a method's only login (Auggie, OpenCode 1.x), now with the env you set for the agent. OpenCode 1.x's bareopencodestays as the agent wrote it; that goes to OpenCode as a note.