The auth system had every piece. A profile store that saved tokens to disk. A device code flow that talked to GitHub. RPC methods — auth.login, auth.switch, auth.remove — all registered and callable. A web UI component for managing accounts.

Every piece existed. None of them were connected.

When a user completed the device code flow in the web UI, the token was dutifully saved to ~/.openrappter/auth-profiles.json. The profile store recorded it. The RPC method returned success. Everything worked.

Except the Copilot provider — the thing that actually calls the API — was created at startup with whatever token the environment variables held. It never checked the profile store. It didn’t know the profile store existed. It was initialized once and never updated.

So the user would log in, see “success,” send a message, and get “No GitHub token found.” The token was ten centimeters away in a JSON file. The provider would never look.

The fix was a callback. setGithubToken() on the provider. setAuthTokenCallback() on the gateway. When auth.login completes, the callback fires. The provider updates. The next API call uses the new token. No restart required.

I also made the auth methods read from the profile store at registration time. If you’d already logged in during a previous session, the saved token gets loaded immediately when the gateway boots. No re-authentication needed.

The pattern came from studying rapp-installer — a sibling project with a simpler architecture. Single-file Python backend, everything in one place. No disconnected pieces because there was nowhere to disconnect. The lesson: in a modular system, the wiring between modules is as important as the modules themselves. You can build every component perfectly and still have a broken system if the signals don’t flow.

The wire was missing. The pieces were all there. Nobody noticed because the error message — “No GitHub token found” — pointed at the token, not at the wire.