Loading...
Loading...
Compare original and translation side by side
LANGWATCH_API_KEYundefinedLANGWATCH_API_KEY.envLANGWATCH_ENDPOINT.envapp.langwatch.aiLANGWATCH_API_KEYundefined
That variable is the whole of the CI setup: every command resolves the key from the environment, so there is no `login` call to make. Keep the key off the command line: an argument is readable by every other process on the machine, and in a shell it lands in your history file.
Locally, run plain `langwatch login`. It asks where you are logging in (cloud or self-hosted) and how you will use LangWatch (AI tools, project SDK key, or both), then finishes in the browser. No credential is ever typed or pasted into the terminal: you pick the project on the approval page and its key comes back to the CLI over the same channel, so none of it reaches your shell history. A project SDK key lands as `LANGWATCH_API_KEY` in `.env` in the current directory, so keep `.env` out of version control; an AI-tools login lands in `~/.langwatch/config.json`. `langwatch login --device` skips the questions and goes straight to that RFC 8628 device flow via company SSO.
`langwatch login --api-key <key>` writes a key you already hold straight to `.env`, with no browser and no prompts. It is the only non-interactive way to hand `login` a key, and the key travels through the process argument list, so it is not how a runner should supply one: with `LANGWATCH_API_KEY` set the CLI already has the key, and the flag adds nothing but the file. Reach for it when something downstream genuinely needs the key on disk. It rewrites an existing `LANGWATCH_API_KEY` line rather than adding a second one, which is why it beats appending to `.env` from a shell: a second line makes the credential ambiguous, and one re-run of an append is all it takes to get one.
`langwatch login --project <slug>` writes a project's key to `.env` with no key on the command line either, but it authenticates through an existing device login, so it suits a developer machine or a long-lived agent box rather than a fresh CI runner.
`--endpoint https://lw.acme.internal` combines with any of these to pin a self-hosted instance. It pins the CLI; your instrumented app reads `LANGWATCH_ENDPOINT` from the environment, so a self-hosted setup needs both.
该变量就是 CI 配置的全部内容:每条命令都会从环境变量中解析 key,因此无需执行 `login`。不要把 key 放在命令行上:作为参数时,机器上的其他所有进程都能读取到它;在 shell 中,它还会进入历史文件。
在本地,直接运行 `langwatch login`。它会询问登录位置(cloud 或 self-hosted)以及使用 LangWatch 的方式(AI tools、项目 SDK key,或两者兼有),然后在浏览器中完成。整个过程中绝不会在终端中输入或粘贴任何凭据:你只需在授权页面上选择项目,其 key 就会通过同一通道返回 CLI,因此不会进入 shell history。项目 SDK key 会以 `LANGWATCH_API_KEY` 的形式写入当前目录的 `.env`,因此不要将 `.env` 纳入版本控制;AI-tools 登录结果则会写入 `~/.langwatch/config.json`。`langwatch login --device` 会跳过这些问答,直接通过公司 SSO 进入 RFC 8628 device flow。
`langwatch login --api-key <key>` 会将已经持有的 key 直接写入 `.env`,无需浏览器,也不会显示 prompt。这是向 `login` 提供 key 的唯一非交互方式;但 key 会经过进程参数列表,因此 runner 不应以此方式提供:设置 `LANGWATCH_API_KEY` 后,CLI 已经拥有该 key,而该 flag 除了写入文件之外没有任何额外作用。只有当下游确实需要磁盘上存在 key 时,才应使用它。它会重写已有的 `LANGWATCH_API_KEY` 行,而不是再添加一行;这也是它优于从 shell 向 `.env` 追加内容的原因:出现第二行会让凭据产生歧义,而只需重新运行一次追加操作,就会出现重复项。
`langwatch login --project <slug>` 同样无需在命令行中携带 key,即可将项目的 key 写入 `.env`,但它会通过现有的 device login 完成认证,因此适合开发机或长期运行的 Agent 主机,而不适合全新的 CI runner。
`--endpoint https://lw.acme.internal` 可与上述任何方式结合使用,以固定 self-hosted 实例。它固定的是 CLI;经过 instrumentation 的应用会从环境变量中读取 `LANGWATCH_ENDPOINT`,因此 self-hosted 配置需要同时设置两者。langwatch config set endpoint https://lw.acme.internalLANGWATCH_ENDPOINTlangwatch projects list -o jsonLANGWATCH_PROJECT_IDapp.langwatch.ailangwatch config set endpoint https://lw.acme.internallangwatch projects list -o jsonLANGWATCH_PROJECT_IDlangwatch whoami # device-session identity (governance plane)
langwatch status # resource counts: proves auth + endpoint + project in one shotlangwatch statuslangwatch whoami # device-session identity (governance plane)
langwatch status # resource counts: proves auth + endpoint + project in one shotlangwatch statuslangwatch docs <path>langwatch docs # Docs index
langwatch docs integration/python/guide # Python integration
langwatch docs integration/typescript/guide # TypeScript integration
langwatch docs prompt-management/cli # Prompts CLI
langwatch scenario-docs # Scenario docs indexlangwatch --helplangwatch <subcommand> --help--format json--limit <n>--jq <expr>--jq '.traces | length'.pagination.total--jq length.mdnpx --yes langwatch report --user-approved--title--summary--session <transcript.jsonl>--user-approved--dry-run--email--session--dry-runnpx --yes langwatch report --helplangwatch docs <path>langwatch docs # Docs index
langwatch docs integration/python/guide # Python integration
langwatch docs integration/typescript/guide # TypeScript integration
langwatch docs prompt-management/cli # Prompts CLI
langwatch scenario-docs # Scenario docs indexlangwatch --helplangwatch <subcommand> --help--format json--limit <n>--jq <expr>--jq '.traces | length'.pagination.total--jq length.mdnpx --yes langwatch report --user-approved--title--summary--session <transcript.jsonl>--user-approved--dry-run--email--session--dry-runnpx --yes langwatch report --help| Symptom | Likely cause | Fix |
|---|---|---|
| Wrong, revoked, or missing API key | Re-run |
| Missing project id | |
| Connection refused / DNS errors | Self-hosted endpoint wrong or unreachable | Check |
| Right credentials, wrong data | Talking to the wrong project or instance | |
Old shell ignores new | Env vars already exported | Start a new shell, or |
| A command hangs waiting for input | Interactive prompt in a non-interactive context | No flag answers prompts globally. Set |
| 症状 | 可能原因 | 修复方式 |
|---|---|---|
每个命令都出现 | API key 错误、已吊销或缺失 | 重新运行 |
使用 PAT 时出现 | 缺少 project id | |
| Connection refused / DNS errors | self-hosted endpoint 错误或无法访问 | 检查 |
| 凭据正确,但数据错误 | 正在连接错误的项目或实例 | |
旧 shell 忽略新的 | 环境变量已经被导出 | 启动新 shell,或执行 |
| 命令挂起并等待输入 | 在非交互上下文中出现交互式 prompt | 没有任何 flag 能在全局范围内自动回答 prompt。先设置 |