A local gateway for two model providers whose module path names a third account

The module path names an account that is neither the owner nor the repository

The Go manifest declares its module as github.com/nghiahoang/launchdock. The repository is nghyane/launchdock. The readme links back to github.com/nghyane/launchdock throughout, including in the badge targets and in the installer URL. Three spellings of one project, and the authoritative one for the Go toolchain is the odd one out: a different handle, with the letters of the two names rearranged. For anyone running this as a binary that changes nothing. For anyone importing it, or building from a fork, or letting a module proxy resolve it, the path in the manifest is the one that gets used, and it does not point at this repository. Nothing else in the file acknowledges the difference, so the mismatch is invisible until a resolve fails.

The version line runs 2.2.8, then 0.1.1, then 0.1.2

Three releases are listed and they do not form an increasing sequence. v2.2.8 was published on 2026-01-30. v0.1.1 followed on 2026-03-28. v0.1.2 followed that on 2026-04-01. So the project dropped two whole major-version numbers between January and March and restarted its count. The technical note explains why without spelling it out: legacy code from a previous name is preserved on a separate path, which means the project was renamed. What that does to a user is concrete. An upgrade path written against the 2.x line does not exist, because 0.1.2 is not the successor of 2.2.8 by any tool's reckoning, and the file offers no table mapping old versions to new ones. The last push on the default branch was 2026-05-01.

The only version-pinning example installs the release before the newest one

curl -fsSL https://raw.githubusercontent.com/nghyane/launchdock/main/install.sh | sh
launchdock version

The default install is one piped line followed by a version check, and the script is fetched from the main branch with no checksum and no pinned commit, which for a tool that handles credentials is worth noting on its own. Underneath it, two optional lines are offered. One sets a version variable and the other sets an install directory, and they are presented as a pair, which reads as two ways to do the same thing when in fact they demonstrate two unrelated flags. The first one names v0.1.1. The newest tag is v0.1.2. So the documented example of pinning a version pins the one before the current release, and neither optional line re-runs the version check that the default block ends with.

The tool holds account logins and one command copies them to another machine

The authentication model is the core of the product and the file describes it plainly. You sign in through the native Claude and OpenAI login flows, and the resulting managed auth is reused across local tools and personal servers. The stated benefit is not copying API keys into configs and shell environments. The cost is that the credentials live as managed state on your machine, and there is a command for moving them: auth push takes a user and host, installs or updates launchdock on that host automatically, and then imports your managed credentials. The documented use is a personal server started over a remote shell. That is a reasonable feature for one person, and it is also the single line in the file that should be read twice before it is typed.

The pid file and the configuration file live in different directory roots

The technical note gives the runtime address as a loopback endpoint on port 8090 and then lists three state paths. The pid file and the log file sit under a dot-directory in your home. The configuration file sits under the conventional per-user configuration location for Linux desktops. So a single process writes its volatile runtime state in one place and its settings in another, and there is no mention of an environment override for either root. For anything that inspects or backs up launchdock state, the practical consequence is that two different directories have to be known, and for anything that resets the tool, that clearing the dot-directory leaves the configuration behind while clearing the configuration alone leaves a stale pid file claiming a process is running.

Three endpoint shapes, five working combinations and one empty cell

The gateway serves three paths and the support matrix crosses them with two providers. The OpenAI-compatible chat path works for both providers and carries tools. The Responses path works for both, carries tools, and speaks the native semantics with reasoning delivered as events and items rather than as a field on a chunk. The Messages path works for Claude only, and the GPT cell in that row is a dash. Five working combinations out of six. The endpoint descriptions draw the useful distinction for a client author: on the chat path, reasoning surfaces through a compatibility field inside the streaming delta, which is the best default for broad client support; on the Responses path it is native. The validation claim behind all of it is narrow. The file says the tool is tested with the official OpenAI Python SDK and was validated locally against two named models across chat, multi-turn, streaming, tool calls and tool result round-trips.

Tool names are rewritten on the way out to clients

One short section explains a translation the gateway performs in both directions of the stack. Claude's own authentication path prefixes tool names with a fixed string when it talks to the upstream service, and launchdock strips that prefix before returning tool and function names to clients, so a client sees the name it originally sent rather than the decorated one. The example given is a plain tool name that would never have carried the prefix upstream, which makes the rewrite hard to picture. Two consequences are left undiscussed. A client that sends a tool name legitimately beginning with that prefix gets it stripped, and a client debugging a mismatch between what it declared and what appears in a transcript sees names that never existed on either side. The section is three sentences long and every one of them describes the normal case.

The readme points at a legacy path that the default branch does not contain

The final line of the file says legacy code from the project's earlier name is preserved on a branch-style path. The top-level listing of the default branch does not include that directory, so the reference resolves only if you know to look somewhere other than where the file lives. Alongside it, several things in the tree have no section at all. There is a web directory in a project whose only documented interface is a local endpoint on one port. Model capabilities exist twice, once as a Go file and once as a data file, and the file does not say which is authoritative. Four terminal interface files are split by operating system, and the authentication interface has its own extra Windows-only file beside the other three. The top level also carries fourteen Go files, which is a flat layout for a project this size.

Editorial conclusion

launchdock is useful if you want one set of account logins feeding several agent tools at once, because it exposes the same two providers through three different endpoint shapes, including the native Messages format that OpenAI-compatible clients cannot speak, and it can install the tool and import your credentials onto a personal server in one command. It is not a good fit if you intend to import it as a library, because the module path in the manifest resolves to an account that is neither the owner nor the repository, and it declares no external module requirements at all, which is a claim worth verifying before you build on it. Before you install, read what auth push does to the remote machine, find where the pid file and the configuration file actually live since they are in different directory roots, and pin a version deliberately, because the only worked pinning example names the release before the newest one.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. nghyane/launchdock on GitHub
4. README
5. Releases