[BUG] Cowork/cloud sandbox: api.telegram.org blocked with 403 connect_rejected, and Pro/Max accounts have no setting to allow it

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

A scheduled task running in the Anthropic cloud sandbox can no longer reach `api.telegram.org`. The agent proxy denies the CONNECT with HTTP 403 (`connect_rejected`, "organization policy"). It worked on 9 September 2026 and was failing by 11 September 2026, with no change on my side.

The account is an individual Max plan with no Team/Enterprise organisation. Per the help centre, only Team and Enterprise owners can configure which domains the sandbox may reach; Free/Pro/Max users get the organisation default and only an on/off toggle at Settings > Capabilities. **So there is no setting available to me that can unblock this.**

Two things make it worse than a simple blocked domain:

1. **It fails silently.** The hourly task is recorded as `SUCCEEDED`. Nothing in the run status indicates the task did nothing. The only signal is the agent's own prose in the run output, which a user is not necessarily reading.

2. **There is no workaround, because the second-choice host is gated too.** `https://api.github.com/` returns 200 at the API root, so it looks allowed — but any repository endpoint returns 403 with `"GitHub access to this repository is not enabled for this session. Use add_repo to request access."`, and `add_repo` is not available inside a scheduled cloud run. So a GitHub-based fallback cannot be built either.

The practical effect is that any scheduled cloud task depending on a third-party API silently became a no-op, with no notification and no user-accessible remedy.

### What Should Happen?

Any one of the following would resolve it:

1. Expose the "additional allowed domains" control to Pro/Max accounts, as Team/Enterprise owners already have.
2. Failing that, publish the default allowlist and announce changes to it, so a scheduled task that depends on a host does not silently stop working.
3. Surface the denial in the run status. A run whose only outbound call was refused by policy should not be reported as `SUCCEEDED` with no flag.

The silent-success behaviour is the part I would prioritise — a blocked domain I can design around once I know about it; a task that reports success while doing nothing, I cannot.

### Error Messages/Logs

```shell
$ curl -sS -o /dev/null -w "http_code=%{http_code}\n" -m 15 https://api.telegram.org/
curl: (56) CONNECT tunnel failed, response 403
http_code=000

$ curl -sS -o /dev/null -w "http_code=%{http_code}\n" -m 15 https://api.github.com/
http_code=200

$ curl -sS -m 20 https://api.github.com/repos//
{"message":"GitHub access to this repository is not enabled for this session. Use add_repo to request access. If add_repo answers that read access is already available and you need GitHub API or write access, call add_repo again with access:\"push\" to attach the repository with credentials."}

$ curl -sS -o /dev/null -w "http_code=%{http_code}\n" -m 15 https://example.com/ # control
curl: (56) CONNECT tunnel failed, response 403
http_code=000

$ curl -sS -o /dev/null -w "http_code=%{http_code}\n" -m 15 https://support.claude.com/
curl: (56) CONNECT tunnel failed, response 403
http_code=000

Proxy status reports the denial as: connect_rejected, gateway 403, organization policy.
Scheduled task run status for the same run: ROUTINE_RUN_STATUS_SUCCEEDED
```

### Steps to Reproduce

1. Use an individual Pro or Max account with no Team/Enterprise organisation.
2. Create a scheduled task (Routine) that runs in the cloud on a cron schedule.
3. In that task, use Bash only — no MCP tools — and run:
`curl -sS -o /dev/null -w "http_code=%{http_code}\n" -m 15 https://api.telegram.org/`
4. Observed: `curl: (56) CONNECT tunnel failed, response 403`, http_code 000.
5. Control in the same run: `https://api.github.com/` returns 200; `https://example.com/` returns the same 403. That pattern matches the documented "package managers only" egress level.
6. Open Settings > Capabilities. Only "Code execution and file creation" and "Allow network egress" are offered. There is no domain list to edit.
7. Check the task's run history: the run is recorded as SUCCEEDED even though its only outbound call was refused.

The same three curl commands run from an interactive Cowork session reproduce it identically, so it is not specific to scheduled runs.

### Claude Model

None

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

Working on 9 September 2026; failing by 11 September 2026. No version pin available — this is the hosted cloud sandbox, not a pinned client.

### Claude Code Version

Claude desktop app 1.49585.0 (Cowork cloud session, not the local CLI)

### Platform

Other

### Operating System

Windows

### Terminal/Shell

Non-interactive/CI environment

### Additional Information

This looks closely related to a cluster of existing open reports about the egress allowlist being ignored, out of sync, or not configurable:

- #38984 — "Additional allowed domains" allowlist non-functional
- #30112 — custom domains blocked with 403 `blocked-by-allowlist`
- #51400 — additional-domain entries not enforced under "Package managers only"
- #37970 — `sandbox.network.allowedDomains` ignored, external APIs blocked
- #19087 — additional allowed domains not applied to container egress
- #34690 — "All domains" setting not reflected in the session proxy JWT

The distinct points in this report are (a) the account tier has **no** domain control at all, so none of the workarounds in those issues apply, and (b) the affected scheduled run still reports `SUCCEEDED`.

Reference for the tier difference: https://support.claude.com/en/articles/12111783-create-and-edit-files-with-claude

No repository files or tests are named. Start by reproducing the curl checks in an interactive Cowork session and a scheduled run, then compare the proxy denial with the recorded ROUTINE_RUN_STATUS_SUCCEEDED status and the available Settings > Capabilities controls. Done means the denial is configurable, announced, or surfaced as a failed or flagged run.

Vom Indexierungsmodell aus dem Issue-Text verfasst.