Error: Remote Control is not enabled for your account. Contact your administrator

Everything up to this point worked. You are signed in, the network is fine, and the request reached something that knew exactly who you are and answered a question about your account. That is what rules out the usual suspects: a rejected credential says the credential is bad, a quota problem names a limit and a reset, an outage does not know your name. This is an entitlement lookup — a capability check against an account — and it returned “no”.

The administrator in that sentence is an assumption

The message is written for an organisation. It assumes there is somebody above you with a console and a toggle. On a personal subscription, that person does not exist, and reading the sentence literally sends you hunting through your own settings for a switch that was never there for your account type.

So the useful first question is not “where do I enable this”. It is: which account is this check being made against, and does that account have anyone who could change the answer? There are three shapes, and they have nothing in common except the error text:

A personal subscription. There is no administrator. Nothing in your settings, environment or config files influences an entitlement the service evaluates. Whether the feature applies to your plan and your surface is a question for the vendor’s own documentation and support, not a configuration problem to solve locally.
A team or enterprise organisation. There genuinely is an administrator, and the message is accurate. What you need is a request, phrased precisely enough to be actionable.
An API key, or a gateway credential. Subscription-side features are not attached to a metered key at all, so there is no “enable” to perform. The interesting question here is why your session is using that credential.

That last case is the one that quietly produces this message for people who are paying for the right plan — which is the next section.

Check which credential is answering, before anything else

The entitlement check is made against whichever identity the session is actually using, and that is not always the one you think you logged in as. /status shows the settings sources in effect and, more importantly, which credential is active. Run it before you contact anyone.

This matters because of a documented and very common misdiagnosis in the same family: a subscriber with a stray ANTHROPIC_API_KEY in their environment has every request routed through a Console key instead of their subscription. The visible symptom in that case is a billing message about credits, but the mechanism is general — an environment variable, a shell profile, a CI secret or an inherited variable in a wrapper script can silently switch the identity that account-level questions are answered about. If /status names a credential you did not intend to use, that discrepancy is your finding, and the fix is your environment rather than the feature.

If the CLI will not start far enough to run /status, claude doctor gives the same class of installation and settings diagnostics from the shell without starting a session.

Is retrying useful?

No. An entitlement lookup returns the same answer every time, immediately.

There is nothing here that refills, queues or recovers: the service asked a question about your account and got a stable answer. No retry-after header accompanies it because there is no interval that would make a difference. A retry loop around this produces identical failures at whatever rate you allow, and in an automated context that is how people discover the problem hours later.

One retry does mean something, but only in a specific place: after somebody has confirmed a change on the account side. Even then, start a new session rather than retrying inside the old one — the check was made with the identity and entitlements resolved when the session began, and a resumed session can reproduce the old answer convincingly enough to make you think the change did not work.

Which case is yours

/status shows an API key and you expected your subscription — an environment variable is redirecting you. This is an identity problem, not an entitlement one, and it explains why a paid plan appears not to have its features.
/status shows the right subscription and you are on a personal plan — there is no administrator to contact. Treat the message’s last sentence as boilerplate, and check the vendor’s documentation for whether the feature covers your plan and the surface you are using it from.
You are in a managed organisation — the message means what it says. The same product family routes other account-level limits the same way: raising an individual spend limit or requesting extra usage on a Team or Enterprise plan is explicitly an “ask your admin” path, not a local setting. This is the same shape.
It worked yesterday and does not today — check what changed about the identity, not about the feature. A new shell, a different machine, a CI runner with different secrets, or a re-login are all far more likely than an entitlement being revoked underneath you.

What to ask for, and who to ask

Environment redirect — remove or unset the variable that is supplying the wrong credential, sign in as the account you intend to use, and start a fresh session. Nothing else in this list applies until /status shows the identity you expect.
Managed organisation — send one message naming the feature exactly as the error names it, the account or group it should apply to, and the work it unblocks. A narrow, specific request is one an administrator can approve on its own merits. “Please turn off the restrictions” asks them to accept responsibility for everything that might follow, and it is the version that does not get answered.
Personal plan — the vendor’s support channel is the only path, and the question to ask is whether the feature is available for your plan at all. That is a much faster conversation than describing it as a bug.
You administer the organisation yourself — then you are the person the message is addressed to, and the control lives in your admin settings rather than in the CLI.

What not to try. The decision is made by the service, not by your client, so client-side settings, environment variables and edited config files cannot change it. If some workaround appears to turn the feature on, you have either found a different feature or built a setup that will stop working without warning — and if the control belongs to your organisation, working around it is also the fastest way to lose the argument for enabling it properly. The productive move is unglamorous: get the request in front of the person who owns the control, with a reason.

Confirming it changed

Start a new session after the account-side change, not a resumed one, and run /status first. Confirm it names the credential and account you expect, and only then invoke the feature.

If the same sentence comes back, do not repeat the account change — check /status again. The most common reason a confirmed change appears not to take effect is that the change was applied to one account while the session is running as another, and the second /status reading is what distinguishes “the change did not work” from “the change did not apply to me”.

Error: Permission to use WebSearch has been auto-denied in dontAsk mode is the other kind of “no”: decided by this session’s configuration rather than your account, which means you or your team can change it locally — the opposite conclusion from this page, so it is worth being sure which one you are looking at.
API Error: authentication_error on OAuth is what a genuine identity failure looks like, as opposed to a successful identity check with an unwelcome answer.
Invalid API key · Please run /login is worth a look if /status surprised you, because it covers the credential states the CLI can be in and how it reports them.
The AI coding error triage tool sorts on the one question that decides who can help you here: was this refused by your account, by your session’s configuration, or by something that actually failed?