---
name: bingai-pass
description: Deploy and use go-bingai-pass — a WASM Cloudflare Worker (or Docker service) that passes Bing AI's Cloudflare/human-verification challenge and returns valid Bing session cookies. Use when the user wants to deploy bingai-pass, "نشر bingai-pass", get a Bing token, bypass the Bing AI captcha/Cloudflare gate programmatically, or fetch fresh Bing cookies for a New Bing / Copilot chat client.
---

# bingai-pass

A small service that solves Bing AI's Cloudflare anti-bot / human-verification gate and hands back valid session cookies, so a New Bing / Copilot client can talk to the chat API without driving a real browser.

Upstream: `Harry-zklcdc/go-bingai-pass`. The deploy scaffolding lives in `assets/`. The actual `.wasm` / Linux binary is **not** bundled — it's pulled from the upstream GitHub release at deploy time.

> The bundled `README.md` carries the upstream disclaimer: the project is for learning/experimentation, is unaffiliated with Microsoft, and the user owns the risk of using it.

## What it exposes

Two endpoints (same for Worker and the Docker binary):

- `GET /gettoken` → returns a JSON token request used to start the challenge.
- `POST /` with a JSON body → solves the challenge and returns cookies.
  - Body fields: `IG`, `cookies`, `iframeid`, `convId`, `rid`, `T`, `host`.
  - Response: `{ "result": { "cookies": "<bing cookies>" }, "error": "<empty on success>" }`.

These are meant to be called by a Bing chat client (e.g. go-vits / bingai front-ends), not by a human directly. The skill's job is to get an instance running and confirm the endpoints answer.

## Deploy options

Pick based on what the user asks. Default to Cloudflare Worker — it matches the user's existing CF setup.

### A. Cloudflare Worker (recommended)

The Worker loads `cloudflare/go-bingai-pass.wasm`, which must be downloaded next to `worker.js` before deploy (it is gitignored upstream).

1. Work from a copy of `assets/` (don't mutate the skill folder):
   ```bash
   cp -R "<skill>/assets" ./bingai-pass && cd bingai-pass
   ```
2. Fetch the WASM into `cloudflare/`:
   ```bash
   curl -L https://github.com/Harry-zklcdc/go-bingai-pass/releases/latest/download/go-bingai-pass.wasm \
     -o cloudflare/go-bingai-pass.wasm
   ```
3. Deploy with wrangler (`wrangler.toml` already points `main` at `cloudflare/worker.js`):
   ```bash
   npx wrangler deploy --keep-vars --no-bundle
   ```
   `--no-bundle` is required so wrangler ships `worker.js` + the `.wasm`/`wasm_exec.js` as-is instead of bundling.
4. Confirm: `curl https://<worker-subdomain>.workers.dev/gettoken` should return JSON, not an error.

For CI instead of local deploy, the upstream workflow `.github/workflows/cloudflare-worker-deploy.yml` (also in `assets/`) does the same with `CF_API_TOKEN` + `CF_ACCOUNT_ID` secrets.

### B. Docker / binary

Runs the full Go binary (downloads a headless browser on first run), listens on `PORT` (Docker default `7860`, binary default `80`).

```bash
cp -R "<skill>/assets" ./bingai-pass && cd bingai-pass
docker compose up -d --build   # exposes :7860
curl http://localhost:7860/gettoken
```

## Environment variables (Docker/binary)

| Var | Meaning |
|---|---|
| `PORT` | API port (binary default `80`, compose sets `7860`) |
| `HTTP_PROXY` / `HTTPS_PROXY` | Proxy, e.g. `http://127.0.0.1:18080` |
| `BROWSER_BINARY` | Path to a browser binary (auto-downloaded if unset) |
| `PASS_TIMEOUT` | Seconds to wait before passing verification |
| `PASS_WAIT_TIME` | Seconds to wait after passing verification |

The Worker build ignores these — it's pure WASM with no browser.

## Workflow when invoked

1. Ask which target (Worker vs Docker) if the user hasn't said. Worker needs a Cloudflare account/`wrangler` login; Docker needs Docker running.
2. Copy `assets/` out to a working dir, fetch the WASM/binary as above, deploy.
3. Verify `GET /gettoken` returns JSON and report the live URL.
4. If the user has a Bing client to wire up, point its "bypass server" / "pass URL" setting at the deployed endpoint.

## Notes

- This circumvents Bing's bot gate. Keep it for the user's own experimentation; don't use it to scrape or abuse the service at scale.
- The WASM and binary are fetched from a third-party GitHub release at deploy time — flag that to the user before running, since the skill doesn't pin a hash.
- If `/gettoken` 500s on the Worker, the most common cause is a missing/old `cloudflare/go-bingai-pass.wasm` — re-download it and redeploy with `--no-bundle`.