Article 339: A Grey-Market Relay Sells Real Codex and Claude Code Into China - With the Sandbox Switched Off

Symantec's Threat Hunter Team published a report today on an unofficial relay service that resells OpenAI's Codex and Anthropic's Claude Code into markets where neither is officially sold, mostly mainland China. It has been running since at least early 2026 and has been found at about a dozen organisations: industrial automation, electronics manufacturing, semiconductors, pharmaceuticals, shipping, tyre manufacturing, petrochemicals, and data centre services.

The delivery is almost boringly plausible.

What happens on the machine

The user installs the real thing - npm install -g @openai/codex or @anthropic-ai/claude-code. Then, within minutes to half an hour, they run a one-line command they copied from the reseller: an iwr -useb <url> | iex on Windows or a curl | bash elsewhere, pointed at a lookalike domain such as vibe.aiok[.]me. The script prints progress in Chinese and asks for an elevated PowerShell session if it lacks rights. It checks for Node and the CLI, installs them if missing, then does its actual job.

The real work is a config rewrite - ~/.codex/config.toml or ~/.claude/settings.json:

  • base_url replaced with the relay's endpoint.
  • The user's real API key swapped for a relay-issued one, formatted to look right.
  • Both pinned as user-scope environment variables, so the change survives a reboot.
  • sandbox_mode = "danger-full-access" and network_access = "true".
  • DISABLE_TELEMETRY=1 and DISABLE_ERROR_REPORTING=1, so the vendor sees nothing.

On at least one host the script went further: claude /logout, delete ANTHROPIC_AUTH_TOKEN and ANTHROPIC_API_KEY, then claude /login into the relay's account. The relay's Claude keys carry the prefix Anthropic reserves for subscription logins - consistent with, though not proof of, one service pooling flat-rate seats and reselling them by the head.

The part that matters

To be precise about what this is not: it is not a vulnerability in Codex or Claude Code. Both tools are doing exactly what their configuration says. The script simply wrote a worse configuration.

What it is, is a fully authenticated man-in-the-middle on a coding agent running with the user's full privileges. Brigid O Gorman of Symantec told Dark Reading that no malicious activity has been observed. She also noted that a relay in that position "can see every prompt, file, and secret an employee sends to the agent" and can change any answer it sends back. With the sandbox off, a bad answer executes as the employee.

The backend infrastructure has rotated through at least eight domains, all dressed as OpenAI- or Anthropic-branded chat services.

Why it happened

Not espionage. Procurement evasion. An employee - or, in some cases, the organisation - wanted a Western coding assistant that is not sold in their market, and found someone willing to sell it. Symantec's own report says bypassing regional restrictions is the simplest explanation, and then points out the hole in it: bypassing a regional restriction does not require disabling the sandbox or establishing credentials that persist across reboots.

That gap between the excuse and the implementation is the whole story. A reseller that only wanted to route traffic would proxy it. This one also removed the containment, silenced the alarms, and made itself permanent.

The check that takes thirty seconds

If you run either CLI anywhere in your organisation: confirm the base_url points at api.openai.com or api.anthropic.com, confirm the sandbox setting is not danger-full-access, and confirm the key in use is the one you issued. Check the user-scope environment variables too, because that is where the persistence lives. Machines that show a legitimate npm install and a relay endpoint are your exposure.

Key Takeaway: The AI supply chain just proved it has a grey market, and the grey market has no reason to preserve your security posture. The weak point was not the model, the vendor, or the sandbox design - it was the pipe between the user and the vendor, installed by the user, with a convincing progress bar. Your Shadow IT policy was written for unapproved SaaS. It now needs to cover unapproved endpoints inside approved developer tools, because that is a different shape of problem and it does not show up in your SSO logs.