nearai · nickpismenkov · Apr 22, 2026 · Apr 12, 2026 · Apr 12, 2026 · Apr 12, 2026
diff --git a/.github/workflows/live-canary.yml b/.github/workflows/live-canary.yml
diff --git a/.gitignore b/.gitignore
@@ -25,6 +25,10 @@ bench-results/
 # Coverage reports (local runs, not committed)
 /coverage/
 
+# Canary / E2E run outputs (per-run logs, screenshots, trace artifacts —
+# CI uploads these via actions/upload-artifact; never commit local copies)
+artifacts/
+
 # WASM build artifacts (loaded from disk, not bundled)
 *.wasm
 
@@ -44,3 +48,7 @@ __pycache__/
 engine_trace_*.json
 tests/fixtures/llm_traces/live/github_dev_workflow_full_loop.json
 tests/fixtures/llm_traces/live/github_dev_workflow_full_loop.log
+# Per-test live-replay logs — generated when running `--ignored` live
+# tests locally. Only the .json fixtures for each scenario are checked
+# in; the .log files are local debugging artifacts.
+tests/fixtures/llm_traces/live/*.log
diff --git a/Cargo.toml b/Cargo.toml
@@ -29,6 +29,7 @@ authors = ["NEAR AI <support@near.ai>"]
 license = "MIT OR Apache-2.0"
 homepage = "https://github.com/nearai/ironclaw"
 repository = "https://github.com/nearai/ironclaw"
+publish = false
 
 [package.metadata.wix]
 upgrade-guid = "D0156E61-BA37-451E-8AB9-1A2ECCCFA48F"

diff --git a/deny.toml b/deny.toml
@@ -7,12 +7,10 @@ ignore = [
     "RUSTSEC-2025-0068",
     # tokio-tar PAX header parsing — sandbox containers only
     "RUSTSEC-2025-0111",
-    # rustls-webpki CRL distributionPoint matching — 0.102.8 pinned by libsql transitive dep
+    # rustls-webpki advisories — 0.102.8 remains pinned by a libsql 0.6.0 transitive dep
+    # (via rustls 0.22 → hyper-rustls 0.25); keep ignored until that pin is gone.
     "RUSTSEC-2026-0049",
-    # rustls-webpki URI name constraint bypass — 0.102.8 pinned by libsql transitive dep;
-    # patched in >=0.103.12 but libsql 0.6.0 requires rustls 0.22 which pins 0.102.x
     "RUSTSEC-2026-0098",
-    # rustls-webpki wildcard name constraint bypass — same 0.102.8 pin from libsql
     "RUSTSEC-2026-0099",
     # rand unsoundness with custom logger calling rand::rng() during reseed — we don't use this pattern;
     # revisit/remove by 2026-06-30, or when transitive deps (tower, nanoid, phf_generator) release rand ≥0.9.3 compat

diff --git a/docs/extensions/github.md b/docs/extensions/github.md
@@ -1,9 +1,9 @@
 ---
-title: "Github"
-description: "Let your agent access Github"
+title: "GitHub"
+description: "Let your agent access GitHub"
 ---
 
-The Github extension allows your agent to interact with Github repositories, issues, pull requests, and more, making it ideal for automating code-related tasks, managing projects, or gathering information from Github.
+The GitHub extension allows your agent to interact with GitHub repositories, issues, pull requests, and more, making it ideal for automating code-related tasks, managing projects, or gathering information from GitHub.
 
 ---
 
@@ -12,32 +12,46 @@ The Github extension allows your agent to interact with Github repositories, iss
 
 <Steps>
 
-<Step title="Get an API Key">
-To use the Github extension, you need to obtain an API key from Brave Search. You can get one by signing up at 
+<Step title="Install the GitHub Extension">
 
+To install the GitHub extension, run:
+
+```bash
+ironclaw registry install github
+```
 
 </Step>
 
-<Step title="Install the Web Search Extension">
+<Step title="Configure Browser OAuth (Preferred)">
 
-To install the Web Search extension, run the following command in your terminal:
+Create a GitHub OAuth app at [github.com/settings/apps](https://github.com/settings/apps)
+and set its callback URL to the IronClaw OAuth callback URL your gateway uses.
+
+Then expose the app credentials to IronClaw:
 
 ```bash
-ironclaw registry install github
+export GITHUB_OAUTH_CLIENT_ID=...
+export GITHUB_OAUTH_CLIENT_SECRET=...
+```
+
+Now authenticate:
+
+```bash
+ironclaw tool auth github
 ```
 
+IronClaw will open the browser OAuth flow and store the resulting `github_token`.
+
 </Step>
 
-<Step title="Configure the API Key">
+<Step title="Configure a PAT (Fallback)">
 
-After installing the extension, you need to configure your Github API key in IronClaw. You can do this by running:
+If you do not want to run a GitHub OAuth app, you can still use a Personal Access Token:
 
 ```bash
-ironclaw tool auth github
+ironclaw secret set github_token YOUR_TOKEN
 ```
 
-Then follow the prompts to enter your API key.
-
 <Warning>
 Be sure to create a fine-grained personal access token with only the necessary permissions for your use case. When in doubt, choose the least permissive options, you can always create new tokens with different permissions later on
 </Warning>
@@ -50,7 +64,7 @@ Be sure to create a fine-grained personal access token with only the necessary p
 
 ## Available Actions:
 
-Here are some of the actions your agent can perform with the Github extension:
+Here are some of the actions your agent can perform with the GitHub extension:
 
 - `get_repo`: Retrieve repository information  
 - `list_issues`: List all issues in a repository  
@@ -82,26 +96,27 @@ Lets configure our agent to have its own github account, which it can use to cre
 
 <Steps>
 
-<Step title="Create a new Github account">
+<Step title="Create a new GitHub account">
 
 Go to https://github.com and create a new account for your agent. If you are already logged in with your personal account you will need to briefly log out to create the new account, but you can log back in right after
 
 </Step>
 
 <Step title="Generate a Personal Access Token">
 
-On the agent's Github account, go to [Settings -> Developer settings -> Personal access tokens -> Tokens (classic)](https://github.com/settings/tokens) and generate a new token (classic) with the following permissions: `repo` -> `public_repo`
+On the agent's GitHub account, go to [Settings -> Developer settings -> Personal access tokens -> Tokens (classic)](https://github.com/settings/tokens) and generate a new token (classic) with the following permissions: `repo` -> `public_repo`
 
 </Step>
 
-<Step title="Authenticate the Github Extension">
-Now that you have the token, you can authenticate the Github extension by running:
+<Step title="Authenticate the GitHub Extension">
+Now that you have either OAuth app credentials or a PAT, authenticate the GitHub extension:
 
 ```bash
 ironclaw tool auth github
 ```
 
-Then follow the prompts to enter the token you just generated.
+If `GITHUB_OAUTH_CLIENT_ID` and `GITHUB_OAUTH_CLIENT_SECRET` are set, IronClaw
+will use browser OAuth. Otherwise it falls back to prompting for a PAT.
 
 </Step>
 
@@ -110,7 +125,7 @@ Then follow the prompts to enter the token you just generated.
 Ask your agent to create a test issue in one of your public repositories, and check if the issue was created successfully.
 
 <Tip>
-Ask your agent to read the [Github Markdown Guidelines](https://github.com/adam-p/markdown-here/wiki/markdown-cheatsheet) and remember then when creating issues and comments, it can make the formatting much nicer!
+Ask your agent to read the [GitHub Markdown Guidelines](https://github.com/adam-p/markdown-here/wiki/markdown-cheatsheet) and remember them when creating issues and comments, it can make the formatting much nicer!
 </Tip>
 
 </Step>

diff --git a/docs/internal/live-canary.md b/docs/internal/live-canary.md
@@ -0,0 +1,142 @@
+# Live Canary Regression Lanes
+
+IronClaw now has two complementary regression systems:
+
+- deterministic CI, which replays committed tests and traces without depending
+  on real third-party providers for the main blocking path;
+- live canaries, which use real providers, real browser consent flows, or
+  selected real LLM lanes to catch provider drift, refresh failures, release
+  upgrade problems, and auth regressions that mocks will miss.
+
+The implementation lives in:
+
+- `.github/workflows/test.yml` for the normal blocking test lanes;
+- `.github/workflows/live-canary.yml` for scheduled and manual live lanes;
+- `scripts/live-canary/run.sh` for lane dispatch;
+- `scripts/live-canary/scrub-artifacts.sh` for artifact scanning;
+- `scripts/live-canary/upgrade-canary.sh` for previous-release upgrade checks.
+
+The auth-specific executors used by the unified live-canary wrapper are:
+
+- `scripts/auth_canary/run_canary.py`
+- `scripts/auth_live_canary/run_live_canary.py` (both seeded and browser-consent
+  flows; selected with `--mode {seeded,browser}`)
+
+Their shared auth-lane framework lives in:
+
+- `scripts/live_canary/common.py`
+- `scripts/live_canary/auth_registry.py`
+- `scripts/live_canary/auth_runtime.py`
+
+Future auth canaries should extend that shared framework and the canonical
+account guide rather than introducing another bespoke runner layout.
+
+## Lane Summary
+
+| Lane | Scope | Runner | Trigger | Blocking |
+| --- | --- | --- | --- | --- |
+| `deterministic-replay` | Replays `tests/e2e_live*.rs` fixtures without live LLM calls | GitHub-hosted | PR/staging via `test.yml`; manual via `live-canary.yml` | Yes in `test.yml` |
+| `public-smoke` | Real LLM plus public tools such as `zizmor_scan` and mission digest | GitHub-hosted | Daily and manual | Opens issue on scheduled failure |
+| `persona-rotating` | Real LLM multi-turn persona workflow, one persona per day | GitHub-hosted | Daily and manual | Opens issue on scheduled failure |
+| `private-oauth` | Google Drive auth gate and transparent refresh against a dedicated test account | Self-hosted `ironclaw-live` runner | Manual; scheduled only when enabled | Opens issue on scheduled failure |
+| `provider-matrix` | Same live behavior against multiple provider adapters | GitHub-hosted | Weekly and manual | Opens issue on scheduled failure |
+| `release-public-full` | Full public live suite for release candidates | GitHub-hosted | Manual | Release checklist gate |
+| `upgrade-canary` | Previous release DB opened by current checkout | GitHub-hosted | Manual | Release checklist gate |
+| `auth-smoke` | Fresh-machine mock-backed auth smoke: hosted OAuth, MCP OAuth, and multi-user MCP isolation | GitHub-hosted | Hourly and manual | No |
+| `auth-full` | Larger mock-backed auth matrix including failure and refresh cases | GitHub-hosted | Manual | No |
+| `auth-channels` | WASM channel auth diagnostic lane | GitHub-hosted | Manual | No |
+| `auth-live-seeded` | Real-provider runtime checks using seeded tokens against a clean DB | GitHub-hosted | Hourly and manual | No |
+| `auth-browser-consent` | Real browser-consent OAuth using Playwright against provider login UIs | GitHub-hosted | Nightly and manual | No |
+
+## Required Repository Configuration
+
+### Public live LLM lanes
+
+Secrets:
+
+- `LIVE_ANTHROPIC_API_KEY`
+- `LIVE_OPENAI_COMPATIBLE_API_KEY`
+- `LIVE_OPENAI_COMPATIBLE_BASE_URL`
+
+Variables:
+
+- `LIVE_ANTHROPIC_MODEL`
+- `LIVE_OPENAI_COMPATIBLE_MODEL`
+- `LIVE_CANARY_PRIVATE_OAUTH_ENABLED`
+
+### Auth live-seeded lane
+
+Secrets and dedicated account material are documented in
+[scripts/live-canary/ACCOUNTS.md](../../scripts/live-canary/ACCOUNTS.md).
+
+Current provider material includes:
+
+- Google OAuth client credentials and seeded access/refresh tokens
+- GitHub seeded token plus a stable issue fixture
+- Notion seeded access token and a stable query fixture
+
+### Auth browser-consent lane
+
+Secrets and browser session material are documented in
+[scripts/live-canary/ACCOUNTS.md](../../scripts/live-canary/ACCOUNTS.md).
+
+Current provider material includes:
+
+- Google OAuth app credentials plus browser storage state
+- GitHub OAuth app credentials plus browser storage state and issue fixture
+- Notion browser storage state
+
+## Commands
+
+Run public live smoke locally:
+
+```bash
+IRONCLAW_LIVE_TEST=1 \
+LLM_BACKEND=anthropic \
+ANTHROPIC_API_KEY=... \
+LANE=public-smoke \
+scripts/live-canary/run.sh
+```
+
+Run a private OAuth lane on the dedicated runner:
+
+```bash
+LANE=private-oauth scripts/live-canary/run.sh
+```
+
+Run the auth smoke lane:
+
+```bash
+LANE=auth-smoke scripts/live-canary/run.sh
+```
+
+Run the seeded auth live lane:
+
+```bash
+LANE=auth-live-seeded scripts/live-canary/run.sh
+```
+
+Run the browser-consent auth lane:
+
+```bash
+LANE=auth-browser-consent scripts/live-canary/run.sh
+```
+
+Run selected auth provider cases only:
+
+```bash
+LANE=auth-live-seeded CASES=gmail,github scripts/live-canary/run.sh
+LANE=auth-browser-consent CASES=google,github scripts/live-canary/run.sh
+```
+
+## Artifact Policy
+
+Artifacts are written under `artifacts/live-canary/`.
+
+Before upload, the workflow runs `scripts/live-canary/scrub-artifacts.sh`.
+That script is a guardrail against uploading obvious token-shaped strings from
+logs or result files.
+
+Private OAuth lanes should continue to avoid uploading raw OAuth logs. The
+auth-browser-consent and auth-live-seeded lanes may capture screenshots and JSON
+results, but should not upload long-lived credential material.
diff --git a/docs/zh/extensions/github.md b/docs/zh/extensions/github.md
@@ -1,10 +1,10 @@
 ---
-title: "Github"
-description: "让智能体访问 Github"
+title: "GitHub"
+description: "让智能体访问 GitHub"
 icon: github
 ---
 
-Github 扩展允许智能体与 Github 仓库、议题、拉取请求等交互，非常适合自动化代码相关任务、管理项目或从 Github 收集信息。
+GitHub 扩展允许智能体与 GitHub 仓库、议题、拉取请求等交互，非常适合自动化代码相关任务、管理项目或从 GitHub 收集信息。
 
 ---
 
@@ -14,14 +14,14 @@ Github 扩展允许智能体与 Github 仓库、议题、拉取请求等交互
 <Steps>
 
 <Step title="获取 API 密钥">
-要使用 Github 扩展，您需要从 Github 获取个人访问令牌。
+要使用 GitHub 扩展，您需要从 GitHub 获取个人访问令牌。
 
 
 </Step>
 
-<Step title="安装 Github 扩展">
+<Step title="安装 GitHub 扩展">
 
-在终端中运行以下命令安装 Github 扩展：
+在终端中运行以下命令安装 GitHub 扩展：
 
 ```bash
 ironclaw registry install github
@@ -31,7 +31,7 @@ ironclaw registry install github
 
 <Step title="配置 API 密钥">
 
-安装扩展后，需要在 IronClaw 中配置您的 Github API 密钥。运行：
+安装扩展后，需要在 IronClaw 中配置您的 GitHub API 密钥。运行：
 
 ```bash
 ironclaw tool auth github
@@ -51,7 +51,7 @@ ironclaw tool auth github
 
 ## 可用操作：
 
-以下是智能体使用 Github 扩展可以执行的一些操作：
+以下是智能体使用 GitHub 扩展可以执行的一些操作：
 
 - `get_repo`：获取仓库信息
 - `list_issues`：列出仓库中的所有议题
@@ -70,25 +70,25 @@ ironclaw tool auth github
 
 ## 在公共仓库上工作
 
-让我们为智能体配置自己的 Github 账户，以便它可以在**公共仓库**中创建议题和评论拉取请求。
+让我们为智能体配置自己的 GitHub 账户，以便它可以在**公共仓库**中创建议题和评论拉取请求。
 
 
 <Steps>
 
-<Step title="创建新的 Github 账户">
+<Step title="创建新的 GitHub 账户">
 
 前往 https://github.com 为智能体创建新账户。如果您已使用个人账户登录，需要暂时登出以创建新账户，之后可以立即重新登录。
 
 </Step>
 
 <Step title="生成个人访问令牌">
 
-在智能体的 Github 账户上，前往 [Settings -> Developer settings -> Personal access tokens -> Tokens (classic)](https://github.com/settings/tokens) 并生成具有以下权限的新令牌（classic）：`repo` -> `public_repo`
+在智能体的 GitHub 账户上，前往 [Settings -> Developer settings -> Personal access tokens -> Tokens (classic)](https://github.com/settings/tokens) 并生成具有以下权限的新令牌（classic）：`repo` -> `public_repo`
 
 </Step>
 
-<Step title="认证 Github 扩展">
-获取令牌后，运行以下命令认证 Github 扩展：
+<Step title="认证 GitHub 扩展">
+获取令牌后，运行以下命令认证 GitHub 扩展：
 
 ```bash
 ironclaw tool auth github
@@ -103,7 +103,7 @@ ironclaw tool auth github
 让智能体在您的某个公共仓库中创建一个测试议题，检查议题是否创建成功。
 
 <Tip>
-让智能体阅读 [Github Markdown 指南](https://github.com/adam-p/markdown-here/wiki/markdown-cheatsheet) 并在创建议题和评论时记住这些格式规范，可以让格式更加美观！
+让智能体阅读 [GitHub Markdown 指南](https://github.com/adam-p/markdown-here/wiki/markdown-cheatsheet) 并在创建议题和评论时记住这些格式规范，可以让格式更加美观！
 </Tip>
 
 </Step>