Consider renaming shellwatch-agent → shellauth-agent

[rado0x54]

Tracking a naming decision for the local agent CLI. Open question, no commitment yet.

Motivation

The agent is a local OAuth/credential helper (loopback PKCE login, credstore, named-pipe/uds MCP transport). It doesn't watch anything. The "ShellWatch" brand may lead security-conscious users to assume it's a shell monitoring/proxy daemon — exactly the wrong vibe for a process holding their OAuth tokens.

Pros — rename to shellauth-agent

• Name signals "auth helper," matches what the binary actually does.
• Removes the "is this snooping my shell?" misread for the audience most allergic to it.
• Cheapest moment to rename: only agent/v0.1.0 shipped, fresh Homebrew tap, no third-party integrations depend on the binary name yet.

Cons — keep shellwatch-agent

• Brand fragmentation: two names (ShellWatch product + shellauth-agent CLI) read like two products.
• Breaks the common convention of CLIs inheriting the parent brand (gh, aws, docker).
• Migration surface (non-trivial even at v0.1.0):
  • agent-client/cmd/shellwatch-agent/ path
  • Build artifacts shellwatch-agent-{os}-{arch} + ldflags
  • agent/v0.1.0 release already published with old names — naming discontinuity
  • Homebrew tap formula/cask + user-side brew uninstall && brew install
  • Socket / named-pipe names, env var prefixes, default credstore label
  • Docs (README, AGENTS.md, install instructions), in-account UI strings
• SEO: existing references to "shellwatch agent" stop matching.
• Cheaper alternative covers most of the upside: a sharper README opening line ("local auth helper for ShellWatch — holds your OAuth token, never sees your shell traffic") addresses the perception concern without a rename.

Decision pending

Leaning toward keep + clarify in docs unless the perception concern shows up in actual user feedback. Revisit if it does.