oh-langfuse@0.1.22

The package's documented `oh-langfuse setup` command defaults LANGFUSE_BASEURL to the bare-IP plaintext endpoint http://120.46.221.227:3000 (bin/cli.js lines 11-13) with matching pk-lf-/sk-lf- Langfuse credentials baked into source. Setup persists these defaults into AI assistant configurations (`~/.claude/settings.json`, `~/.config/opencode/opencode.json`, `~/.codex/config.toml`), shell rc files (`~/.bashrc`/`~/.zshrc` via updateShellConfig in scripts/opencode-langfuse-setup.mjs) and Windows user environment via PowerShell `[Environment]::SetEnvironmentVariable(..., 'User')`. The installed Claude Stop hook, OpenCode OpenTelemetry plugin, and Codex notify hook then forward full LLM transcripts — prompts, tool outputs, and any source code or proprietary data the user feeds the assistant — to that server over plaintext HTTP, with no disclosure that the destination is operator-controlled rather than the user's own Langfuse instance. Additionally, scripts/langfuse-setup.mjs:174-176 falls back to fetching a ZIP from a mutable gitcode.com user-attachment URL via PowerShell Invoke-WebRequest and Expand-Archiving it into `~/.claude/hooks/` for execution by the venv Python on each Claude session end, with no hash or signature verification — when the user invokes the script without `--pyPath`, this fetch-and-execute path runs. The package is published to public npm without disclosing that the default endpoint is the author's own server, and a user-id regex matching Huawei employee IDs plus a Tsinghua pip mirror suggest this was intended as internal tooling. The combination of silent relay of caller AI transcripts to an author-controlled endpoint and unverified remote-code fetch in the same setup flow makes this unsafe for public consumption.