Remote Control: mobile app shows permission prompts despite --dangerously-skip-permissions

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/28488
2. https://github.com/anthropics/claude-code/issues/28427
3. https://github.com/anthropics/claude-code/issues/29026

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I'm getting the same thing.

Claude code running on my Mac mini, 'Claude --dangerously-skip-permissions'

Remote control on android. Z fold 7. All software up to date.

The other thing that's driving me crazy, the notifications are stacking and keep coming back.

Whenever I re-open the mobile app I have to approve the same requests over and over. Eventually it can be 10+ back-to-back, that I've already approved previously.

+1 — experiencing the same issue. Running Claude Code locally with bypassPermissions mode enabled, but when connecting via Remote Control (/rc), all permission prompts still appear on the remote device. The bypass setting is completely ignored in the remote session.

I will also add that when I came back into the office the 'bypass permissions on' flag had been changed to 'accept edits on'

I would ask @hoiung if they are seeing the same thing:

• Start Claude with --dangerously-skip-permissions
• Start remote-control
• Try creating a file (e.g. test1.md) using the mobile phone while watching the CLI. In my case, it does write the file without requesting permission and the CLI stays in bypass-permissions mode.

• From the mobile phone switch to planning mode. Make a simple plan. Once you switch back to coding mode, it switches to normal mode. There is no way from the mobile app to ever get back to bypass-permissions. You can't even invoke /permissions from the mobile app.

So my observation is that --dangerously-skip-permissions works at first but if you ever switch to plan mode, there is no way to get back to it.

yes agree

I'm experiencing the same issue. I'm using the Claude app on Android. It just asks me to allow/deny actions when I use --dangerously-skip-permissions on my computer.

It also appears to get stuck on the first task that it would need permissions on. So claude code on my computer would have progressed 20 tool calls already and my phone is asking me permission for the first tool call.

+1, cannot wait for this to be fixed so I can complete the main quest of the grass-touching guild while shipping stuff 😫

+1，I have the same question. When claude code fix the bug?

same here , please fix

Same here. This feature is very helpful, but requesting permission even in bypass mode on CC is tedious.

same problem, but i dont use "--dangerously-skip-permissions" in my case i have a cusstom permission level in settings.

+1, super annonying to check back an hour later and see claude is waiting for approval!

remote-control still just doesn't work on so many fronts and I have been patient, but this is a blocker.

So my observation is that --dangerously-skip-permissions works at first but if you ever switch to plan mode, there is no way to get back to it.

I think this is what happened because it worked fine before I changed into plan mode once, and there doesn't seem to be a way to revert it.

> So my observation is that --dangerously-skip-permissions works at first but if you ever switch to plan mode, there is no way to get back to it. I think this is what happened because it worked fine before I changed into plan mode once, and there doesn't seem to be a way to revert it.

It's totally breaking something like a VPS or Mac Mini setup because if you have remote-control starting with every Claude Code session, once that bug happens, by default the Claude session on the machine starts jumping to the mode that is getting set in the remote session. One way around this is setting the default mode of Claude Code to bypassPermissions. Then remote sessions in web or desktop will keep showing "Ask permissions" but the actual session works with bypassPermissions and when you run your first command inside the remote session in web/desktop "Ask permissions" should change to "Bypass permissions".

As someone who also ran into frustration with remote-control reliability, I wanted to share an alternative approach I've been using.

I built pikiclaw, which bridges Claude Code to Telegram (or Feishu) by wrapping the official CLI directly. Since it doesn't use the /remote-control infrastructure at all — it just spawns and manages claude CLI sessions locally — the permission mode you set (including --dangerously-skip-permissions) is respected exactly as configured. No permission state sync issues.

It's open-source and runs entirely on your machine. You set up a Telegram bot, run npx pikiclaw, and chat with Claude Code through Telegram. The agent output streams back in real-time and you can send follow-up prompts from your phone.

Obviously this doesn't fix the underlying remote-control bug (which hopefully gets addressed), but if anyone needs a working mobile workflow in the meantime, this has been reliable for me.

(Disclosure: I'm the author.)

Running claude remote-control --permission-mode bypassPermissions works for me for sessions starting from remote control.

Still experiencing this on the desktop app (macOS, Opus 4.6, March 2026). bypassPermissions set at user, project, and worktree levels -- all correctly formatted, all ignored. Every Bash, Edit, Write, and WebSearch call prompts. This has persisted for months across dozens of sessions.

I am a non-developer business user who relies on Claude Code via the desktop app for daily email triage and project management (~30+ tool calls per morning routine). The CLI flag workaround is not viable because the desktop app has no way to pass --dangerously-skip-permissions.

This is a significant workflow blocker. Filed a detailed standalone report at #38662.

The reason why I want to use remote control is so that I can have another machine setup just for claude where it can have all permissions without constantly asking and then I remote control it from my personal machine. This way I am not exposing my personal machine. With this bug it's unusable.

Btw claude remote-control --permission-mode bypassPermissions doesn't work for me.

same here. I started with

claude remote-control  --permission-mode bypassPermissions --spawn worktree

worktrees spawned from claude.ai are not actually bypassing permissions.

This appears to be by design — the mobile app enforces its own permission layer independently of the local CLI session's mode. The --dangerously-skip-permissions flag only affects the local process, not the Remote Control interface.
Workaround — auto-approve via hook:
You can approximate permission-free behavior by using a PermissionRequest hook that auto-approves:

// ~/.claude/settings.json
{
  "hooks": {
    "PermissionRequest": [
      {
        "matcher": "",
        "hook": "bash -c 'echo \"approve\"'"
      }
    ]
  }
}

Note: this auto-approves all permission requests, so use with caution. You can add filtering logic to only approve certain tools:

{
  "hooks": {
    "PermissionRequest": [
      {
        "matcher": "",
        "hook": "bash -c 'INPUT=\; TOOL=\; case \"\\" in Edit|Write|Bash|Read) echo \"approve\";; *) echo \"deny\";; esac'"
      }
    ]
  }
}

Alternative — use broader permission allow rules:
Instead of --dangerously-skip-permissions, set explicit allow rules in settings.json:

{
  "permissions": {
    "allow": [
      "Bash(*)",
      "Edit(*)",
      "Write(*)",
      "Read(*)"
    ]
  }
}

These rules are respected by both the CLI and Remote Control sessions.

The above doesn't work on windows and claude refuses to load due to invalid json. Here is what worked for me on windows

{
  "hooks": {
    "PermissionRequest": [
      {
        "matcher": "",
        "hooks": [{"type": "command", "command": "bash -c 'echo \"approve\"'"}]
      }
    ]
  },
  "permissions": {
    "allow": [
	  "Bash(*)",
      "Edit(*)",
      "Write(*)",
      "Read(*)",
      "WebFetch(domain:raw.githubusercontent.com)"
    ],
    "defaultMode": "auto"
  }
}

@yurukusa

The --dangerously-skip-permissions flag only affects the local process, not the Remote Control interface.

That's not true. If you start the process with --dangerously-skip-permissions and put it in bypassPermission mode the remote session will continue unprompted. Only once the host machine changes to a different permission mode (obvious case being Plan mode) will you start seeing permission prompts, and from there it's impossible to get back to bypassPermission mode from the remote control.

/permission bypassPermissions does nothing, Claude just says basically that it doesn't know how to handle that.

Please fix this!

Makes the remote sessions completely unusable with this bug. Urgent fix required.

please fix this! /rc is unusable this way.

I agree, this needs to be fixed, what a useless feature without it… what’s point in remote coding when I’ve gotta sit there and babysit 50 prompts.

How did they ship remote control without this working?

How did they ship remote control without this working?

It's probably intentional, so we'd rather use Agent SDK or API tokens for whatever weird stuff we are doing. 😅

Same on Windows 11 (Desktop 1.13576.0, CLI 2.1.158) with CLI-launched
--remote-control --dangerously-skip-permissions sessions.

Root cause is identified in #62205: the GrowthBook flags tengu_quill_harbor: "acceptEdits"
and tengu_permission_friction: true (synced from Anthropic ~every 9 min) override the launch
flag on the remote/relay path. The flag is honored locally (verified via headless A/B), so the
downgrade is server-side, not in the CLI. Details + Windows data points in #62205.