DEV Community: Erkan Ciftci

Remote Control for API-Based Claude Code: Approve Bedrock, Vertex & Foundry Sessions From Your Phone (Claude Mobile App)

Erkan Ciftci — Sun, 04 Oct 2026 14:13:10 +0000

Claude Code’s Remote Control needs a Claude subscription login, so API-provider sessions are stuck in the terminal — here’s how I gave them one back with hooks, a file queue and a single Python file

ccBridger: Remote Control for API-based Claude Code sessions (Bedrock, Vertex, Foundry)

TL;DR — Claude Code’s Remote Control needs a Claude subscription login. Sessions that run through an API provider — AWS Bedrock, Google Vertex AI, Microsoft Foundry — don’t get it, so a single permission prompt can stall an hour of work while you are in a meeting.

ccBridger is a small open-source bridge: hooks record what the session needs, a tiny helper session shows it in the Claude mobile app as a native prompt, and your tap goes back to the terminal.

No server, no open ports, no additional application, standard library only.

🔗 github.com/fxerkan/ccbridger

The problem

A lot of companies run Claude Code through their cloud provider instead of a Claude subscription: AWS Bedrock, Google Vertex AI or Microsoft Foundry. The reasons are sensible: billing lands on the cloud invoice, data stays inside the account, access goes through the provider’s own identity system. I work that way on two client projects, both on Bedrock.

What you give up is Remote Control. With a subscription login you can open the Claude app on your phone, see the session that is running on your laptop, answer its questions and keep it moving. With an API provider that door is closed. The session lives in the terminal tab where you started it, and nowhere else.

That sounds like a small inconvenience until you look at how agent work actually goes:

You start a long task — a migration, a refactor, an infrastructure change — and go to a meeting.
Eight minutes in, the agent wants to run a command it isn’t allowed to run on its own. It asks. Nobody answers.
You come back fifty minutes later to a prompt that says “Do you want to proceed?” and an agent that has done nothing since.

The other failure mode is worse. To avoid the stall, people start sessions with --dangerously-skip-permissions. Now nothing waits for you — including the things that should.

And it isn’t only permissions. Agents ask real questions too: “The upgrade can’t be rolled back. Test workspace first, or straight to prod?” That is exactly the decision you want to make yourself, and exactly the one that sits unanswered while you are away.

The same prompt, two outcomes: without the bridge it waits at an empty desk for 48 minutes; with ccBridger the answer costs ten seconds from your phone

An analogy before the tech

Picture a contractor renovating your kitchen while you are at work. They are good and fast, but they have one rule: before knocking down a wall, they ask. If they can only ask by knocking on your study door, the work stops the moment you leave the house. Give them your phone number and the same rule costs you ten seconds instead of an afternoon.

ccBridger is the phone number. The rule — ask before doing something that matters — stays exactly as it was.

Why the obvious answers don’t fit

“Just SSH in and attach to tmux.” Works, on a laptop keyboard. On a phone, typing into a terminal UI to press 1 is miserable, and you only find out there is something to answer if you go and look.

“Build a web dashboard.” Now there is a server to run, a port to expose, authentication to get right, and a new place where your prompts and commands live.

“Wrap the CLI.” A wrapper has to sit between you and the terminal all the time, and it changes how you start every session.

“Skip permissions.” See above.

What I wanted was narrower:

Keep working exactly as before. If I’m at the keyboard, nothing changes. If I’m not, the question finds me — in an app I already have, on an account I already own — and my answer goes back. Nothing to host.

The idea: borrow the Remote Control you already have

Remote Control doesn’t work for the API-based session. But it works fine for a different session on the same machine that runs on my own Claude login. So the bridge doesn’t try to remote-control that session at all. It starts a tiny second session whose only job is to ask me a question, and lets Remote Control carry that question to my phone.

Three pieces make that work.

ccBridger architecture: a permission request leaves the API-based session through hooks, lands in a plain-file queue, and after 15 seconds a relay session running on your own Claude login carries it to the Claude mobile app; your tap maps back to a decision file and unblocks the terminal

1. Hooks on the API-based session

Claude Code runs hooks — shell commands — at defined points.

ccb install adds five of them:

PermissionRequest — Writes the request (tool, input) to a file, then waits for a decision file. The terminal prompt stays live the whole time.

Stop, SessionStart, UserPromptSubmit, Notification — Keep one background waiter per session alive.

The decision goes back as the hook’s JSON output:

{"hookSpecificOutput": {"hookEventName": "PermissionRequest",
                        "decision": {"behavior": "allow"}}}

The waiter is how a message reaches an idle session. Those four hooks are registered with asyncRewake : they run in the background, and when one exits with code 2, Claude Code wakes the session and hands it the hook’s stderr. So the waiter polls an inbox file; when a message lands, it prints the message and exits 2. The idle session wakes up and treats it as something the user said.

Four hooks for one waiter looks redundant. It isn’t: a turn interrupted with Esc never fires Stop , so without the others the waiter would be gone until the next full turn.

2. A file queue

All state is plain files under ~/.claude/ccbridger/ , one directory per session: pending.json, decision.json, inbox, waiter.pid. Writes are atomic renames; the inbox is taken with a rename so exactly one waiter gets each message. Polling is once a second. There is no daemon and nothing listens on the network.

Which sessions exist, and whether each is idle, busy or waiting, comes from Claude Code’s own registry in ~/.claude/sessions/. What a session is doing comes from its transcript file. ccb ls and ccb show are just readers for those two things.

3. The relay session

When a request has waited 15 seconds without a local answer, the hook starts the relay in tmux (simplified):

claude --model haiku --tools AskUserQuestion --remote-control "Approval - Prod deploy - infra" \
       --append-system-prompt "<relay instructions>" --settings '<two hooks>' "<the request>"

A few things about that line matter:

It runs on my Claude login , with the provider variables ( CLAUDE_CODE_USE_BEDROCK, …_VERTEX, …_FOUNDRY ) stripped, so Remote Control is available.

It has exactly one tool , AskUserQuestion. It cannot read files or run commands. Its whole job is to turn the request into a native question in the Claude app.

The model never decides anything. A PostToolUse hook on the relay reads the answer I tapped and writes the decision file itself. Only the exact Approve label counts as approval; anything else — Reject, free text, a typo — is a rejection.

There is one relay per bridged session and it stays open, so the conversation on the phone becomes a readable history: what was asked, what I answered, in order. Its title follows the topic of the latest request.

In the Claude mobile app: a blocked permission request from a Bedrock session arrives as a native Approve/Reject prompt, and a two-way conversation with a Vertex session where an AskUserQuestion is answered by option number.

Questions, and why answers are mapped by position

When the bridged session calls AskUserQuestion , the relay asks the same question with the same options. Early on I noticed the small relay model sometimes shortened the option text. For a question like “upgrade prod now?” that is not a detail I wanted to leave to chance.

So the relay hook doesn’t forward the label I tapped. It finds the position of my choice among the options the relay showed and maps it onto the option at the same position in the original question. The wording on the phone can drift; the answer cannot. The original text is always in the message right above the prompt.

A two-way conversation

Approvals were the starting point, but once the relay existed the next step was obvious. The relay has a UserPromptSubmit hook: anything I type into that conversation that isn’t one of ccBridger’s own messages is put into the session’s inbox instead of being answered by the relay model. The waiter delivers it. When the session finishes its turn, its Stop hook pastes the final message back into the relay.

So from the phone I can write “ Is the upgrade done? Are all the filters working? ” and get the real session’s answer in the same thread. If the session is busy, I’m told so, along with what it is doing right now and that my message is queued.

Teams: one cloud account, many people

API access is often shared across a team — one AWS account, one GCP project, one Azure resource. The bridge is not shared, and that falls out of the design rather than being added to it:

Every developer installs ccBridger on their own machine. State lives under their own ~/.claude.

The relay runs on that person’s own Claude login, so prompts land only in their Claude app. Nobody can see or answer anyone else’s.

There is nothing central to run, patch or secure.

For anything beyond the app, each person can set a notify_cmd in their config — a shell command that runs once per request with the title and body in its environment. That covers Slack, ntfy or a pager, per user. People without a Claude subscription can turn the relay off and answer with ccb ok over SSH.

This isn’t just my problem — the open requests it answers

I didn’t invent this gap. It’s one of the most-upvoted things on the Claude Code issue tracker. ccBridger doesn’t fix Claude Code — it’s a parallel sidecar, not a product change — but it covers the day-to-day need in these threads. Honestly, and partially:

#28795 — Bedrock + AWS SSO in Remote Control. The ask: enterprise users on CLAUDE_CODE_USE_BEDROCK=1 + AWS SSO want Remote Control without a separate Claude subscription. Signal: 131 👍, 13 comments — the flagship request

→ ccBridger : Partially delivers the everyday capability (approve/answer/message a Bedrock session from the phone) through hooks + a relay — different mechanism, not native decoupled auth.

#90606 — Permission dialog hangs the host terminal. The ask: a permission prompt with no one at the keyboard blocks the whole session indefinitely. Signal: lower volume, but exactly on point.

→ ccBridger: Solves it. This is the flagship feature — after 15 seconds with no local answer, the prompt is on your phone, and the terminal stays live the whole time.

#35637 — Permission prompts don’t render on mobile. The ask: Remote Control shows the session but the actual Approve/Reject prompt never appears on the phone. Signal: 30 👍, 23 comments.

→ ccBridger: Solves the symptom. API-provider prompts arrive as a native Approve/Reject card — only the exact Approve label counts.

#28508 — Mobile AskUserQuestion answer doesn’t return to the CLI. The ask: you tap an answer on the phone and the terminal never receives it. Signal: 27 👍, 19 comments.

→ ccBridger: Solves the symptom. The answer is mapped back by position, so the wording can drift on the phone but the choice can’t.

#95744 — Non-Anthropic provider + Remote Control in one session. The ask: one session that is both on an API provider and remote-controllable. Signal: newer, growing.

→ ccBridger: This is the whole architectural thesis — ccBridger splits those two jobs into two processes instead of forcing one session to do both.

Two honest caveats that belong right here, not buried: ccBridger doesn’t remove the subscription requirement — it moves it to a second Claude login on the same machine (the relay). And it’s macOS/Linux + tmux , not Windows, and ZDR/compliance setups are out of scope. If you can’t run a Claude login at all, you can turn the relay off and answer with ccb ok over SSH, or wire a notify_cmd to Slack/ntfy/a pager.

Getting started

git clone https://github.com/fxerkan/ccbridger.git && cd ccbridger
ln -s "$PWD/ccbridger" ~/.local/bin/ccbridger
ln -s "$PWD/ccbridger" ~/.local/bin/ccb # short alias
ccb selftest

ccb install --global # every Bedrock / Vertex / Foundry session
# or: ccb install ~/code/project-a ~/code/project-b

--global stays out of the way of sessions that already run on a Claude login. Restart the sessions you want bridged, and that’s it. From any terminal:

ccb ls # sessions, status, what is pending
ccb show infra # what that session has been doing
ccb ok infra # approve · ccb no infra "not on prod"
ccb answer infra 1 # answer a question by option number
ccb send infra "run the tests again and summarise the failures"
ccb open infra # open the phone conversation without waiting for a request

What I learned building it

A few things only showed up once it met real sessions:

A hook is not killed when you answer locally. The PermissionRequest hook kept waiting after I pressed Enter in the terminal, so requests looked pending forever. It now watches the session’s status and leaves when the session stops waiting.

Pressing Enter in the wrong place approves things. The relay is driven through tmux. Sending Enter while a question is on screen selects the first option — Approve. The code checks what is on screen before it sends a key, and a second hook process for the same request is not allowed to ask twice.

Text pasted too early disappears. A follow-up request pasted into the relay while it was still finishing the previous one was silently lost. It now waits until the relay is idle.

My own test sessions reached my phone. They ran on my login, so their prompts showed up in my app and I answered one without knowing what it was. For a while I blamed Claude Code for “ignoring” an answer that I had, in fact, overridden myself.

Honest limits

A session started with -- dangerously-skip-permissions never asks, so there is nothing to approve. Watching and messaging still work.

Only the last message of a turn comes back to the phone, not every step.

Answers to questions reach the session as text; in the terminal that shows up as a denied tool call followed by the session carrying on with your answer.

It depends on things Claude Code doesn’t promise to keep stable: the session registry, the hook behaviour, a few strings on the terminal screen. A future release can break it. The built-in self-test covers the queue logic, not the live integration.

Developed and tested on macOS, with live sessions on AWS Bedrock. Vertex AI and Foundry go through the same hooks and are detected the same way, but I haven’t run live sessions on them yet. Linux should work; I haven’t tried it either.

Why this matters

Permission prompts are the part of agent tooling that keeps a human in the loop. The moment they become an obstacle, people remove them. I would rather make saying yes or no cost ten seconds from wherever I am than choose between an agent that waits all afternoon and one that never asks.

The whole thing is one Python file, MIT-licensed, with no dependencies. Read it, run the self-test, and watch the network: there is nothing to see there.

Links

⭐ GitHub: github.com/fxerkan/ccbridger

📦 Install: git clone · ln -s · ccb install — global

If this was useful, a ⭐ on GitHub helps other people who are stuck at the same prompt find it.

Developed by FXerkan — Code more, worry less.

You Just Shared Your API Key With an AI. You Didn’t Even Notice.

Erkan Ciftci — Fri, 18 Sep 2026 05:37:56 +0000

Why the AI-coding era needs a local-only AI secret manager — and how I ended up writing one in a single Python file

TL;DR — Coding assistants read your repository to help you. The moment an API key lands in a .env file, it can end up in a chat transcript, a log, or a bug report. concealer is a local-only, open-source AI Secret Manager that keeps secrets encrypted and on your machine — while still letting your agents use those secrets without ever seeing them.

🔗 github.com/fxerkan/concealer

The problem nobody warned us about

For a decade, the .env file was a reasonable compromise. Plaintext, sure — but it sat on your machine, git ignored it, and you were the only one reading it.

Then our editors grew a brain.

An AI coding assistant has to read your files to be useful; that's the whole job. It scans the repo, suggests fixes, runs commands, pipes the output back into a model. And somewhere in that repo sits a file that starts like this:

OPENAI_API_KEY=sk-live-...
AWS_SECRET_ACCESS_KEY=wJalr...
DATABASE_URL=postgres://user:hunter2@db:5432/prod

That key is now one cat .env away from a context window. You can guess the rest:

it gets echoed into a chat transcript you later paste into an issue,
it gets caught in a log the agent streams back,
it sits in the model's context for the rest of a long session,
it gets committed by accident when the agent "helpfully" stages every file.

All of these are real leak paths, and none of them existed when .env was invented. The threat model moved. Our tooling stayed put.

An analogy before the tech

If you don't write code for a living, picture this instead. You've hired a wonderfully capable house assistant. They tidy up, remind you about bills, find any document in seconds. One small detail: for years you've been writing all your passwords on a sticky note on the fridge. The assistant doesn't need to be malicious — they do their job by reading your house, and that note is part of the house.

What concealer does is, at its core, exactly this simple: it takes the note off the fridge and puts it in a locked drawer. The assistant can still ask what's in the drawer — "is the electricity account on file?" — and hears "yes, it's on file." They can say "pay this bill" and the bill gets paid, but the card number never leaves the drawer. And every time anyone opens the drawer, it goes into a ledger.

The rest of this post is the technical version of that drawer. Even if you never touch a terminal, the idea carries: let the assistant do the work, without ever showing it the secrets.

Why the obvious answers don't fit

The reflex answer is "just use a secret manager." Look at what that actually means in practice:

Cloud vaults (Vault, Doppler, cloud KMS): an account, a network round-trip, a service that has to stay up. Heavy for a solo dev or a laptop project — and now your secrets live on someone else's server.
Password managers (1Password and friends): great for humans, clumsy for scripts and agents. And tied to an account.
OS keychains: tied to the machine. Wipe your laptop or switch to a new one, and your vault doesn't come along.
.env files: plaintext. The exact thing we're trying to get away from.

What I wanted was narrower, and I think more honest about how we actually code now:

Local-only. No cloud, no account, no telemetry. Portable — copy the files, type one password, decrypt anywhere. And designed with agents in mind, so an assistant can use a secret without the value ever entering its context.

Nothing on the shelf did all four. So I sat down and wrote it.

Meet concealer

concealer is a single Python 3 script (standard library only, no pip dependencies) wrapping two battle-tested tools:

SOPS — born at Mozilla; encrypts a YAML/JSON file without wrecking its structure.
age — Filippo Valsorda's modern, unflashy, correct encryption.

On that foundation it adds what you'd actually want from a secret manager: typed secrets, scoping by project and environment, a web console, a tamper-evident audit log, and — the part I care about most — an MCP server so AI agents can use secrets safely.

All the encryption is deliberately left to SOPS and age; concealer doesn't invent its own cipher. The only crypto it does itself is verifying your password with the standard library's scrypt and chaining the audit log with HMAC. Boring, I know. In security, boring is a compliment.

The whole system on one page: five interfaces funnel into a single-file core that shells out to SOPS + age. Neither the encrypted vault nor the keys ever leave your machine.

The feature I actually built this for: agents that never see the secret

This is the part that separates concealer from just another vault — the part that makes it an AI-era tool.

concealer ships with an MCP server (Model Context Protocol — the standard way agents talk to tools). An agent can do two things:

List secret names. "What database credentials exist for this project?" It gets back names only. Never values.
Run a command with a secret injected. The value is decrypted, handed to a child process's environment, the command runs — and the secret values are redacted from the output before the agent gets to read a single line.

The plaintext never enters the agent's context. Not on the way in, not on the way out.

The agent asks for names, then asks concealer to run a command with a named secret. The value lives only inside the child process; the output comes back redacted; the whole exchange lands in the audit log — names and actions only, never values.

And since "an agent that can read secrets" is a risk all by itself, concealer stays on the cautious side and guards against bulk theft too:

Registration is mandatory. Only a registered agent token can call the MCP tools. A human/CLI token, or no token at all, gets access denied.
Least privilege, by contract. The agent has to name the exact secrets a command needs, one by one — there is no "give me everything."
Rate limits against exfiltration. Two per-agent caps: how many rows a single call may return, and how many distinct secret names an agent may reveal within a rolling time window. Names it has already seen re-list freely; new ones count against the quota. Bulk enumeration gets throttled and logged.

Think of a valet key: the valet can park your car but can't open the trunk. The agent never holds the key — concealer turns the lock, and the agent only sees the result.

Here it is live — Claude Code using a Home Assistant token through concealer MCP; the value never enters the agent's context:

Claude Code injecting a Home Assistant token via concealer MCP — the value never appears - demo-ha-token

Five ways in, one encrypted vault

Same vault, whichever way you like to work.

CLI — everything from the terminal

Set, read, run-with, and deploy secrets from the terminal, scoped by tenant / project / environment / repo. cer run injects values into a child process and scrubs them from its output — the value never touches your terminal.

cer set --name OPENAI_API_KEY --project web --env prod 'sk-DUMMY-123'
cer run --project web --env prod npm run deploy

Web UI — a local console

Run concealer web and open http://127.0.0.1:8787. Forms that adapt to the secret type, searchable filters, per-secret deploy templates, clipboard copy that clears itself, dark / light / matrix themes, full TR/EN localization. localhost only — this is your console, unlocked with your master password.

The main vault view: secrets filtered by project and environment, values masked until you reveal them.

Secrets are typed, not just key/value blobs: database credentials, cloud keys, web logins, custom multi-field records — each with the right fields and the right masking.

A database record with structured fields. Masking is record-aware: a value that looks like user:pass@host gets masked even in a "plain" field.

A secret manager should also help you find your risk. That's what the risk dashboard in the Web UI is for: values reused across secrets, overly broad scopes, even a scan of your shell history for keys you forgot there.

And every action shows up in a tamper-evident audit viewer:

Each line is appended to an HMAC-SHA256-chained log with a monotonic sequence number and a tail anchor — deletions and reordering stand out. Names and actions only, never values.

TUI — without leaving the terminal

If you'd rather stay in the terminal, concealer tui opens a full-screen browser: arrow keys, instant filtering, type-aware editing, add / delete / reveal — no browser tab in sight.

MCP — for AI agents

Covered above: register an agent, hand it a revocable token, and it can use secrets it never sees. concealer agent register <name>.

An agent listing concealer secrets over MCP — names only, never values - (mcp-secret-list)

Chrome Extension — copy from your toolbar

Sometimes you just need to paste a value into a web form. The Chrome extension opens your vault and copies values straight from the toolbar. Multi-field records expand for per-field copy and reveal; the popup locks itself when idle.

The security model, briefly

Without overselling it — concealer's security comes down to a few deliberate choices:

The key is encrypted at rest. On a hardened vault, the age private key is never written to disk in plaintext. It sits master-password-encrypted (age-key.txt.age), gets decrypted in memory, and is handed to SOPS through an environment variable — not a temp file.
Unlock tokens live client-side only. The token value exists only in your environment (CONCEALER_TOKEN); disk holds just its scrypt hash and a token-wrapped copy of the key. Tokens can be revoked and can expire. Humans get a short-lived one via unlock; agents get a long-lived but revocable one via agent register.
Recovery codes as a second factor. init prints eight one-time codes, shown once. Rotating the master password requires one of them — so a stolen password alone can't take over the vault.
Tamper-evident audit. The HMAC-chained log plus a tail anchor makes truncation and reordering detectable. (The honest ceiling: an attacker with both filesystem root and the audit key can rewrite the chain — the docs say so, in plain words.)

No security model is magic. But everything here is written down, readable, and the actual cryptography is left to tools that have earned their trust.

Portable by design

Your vault is just a handful of files. Copy keys/ and secrets.enc.yaml to a new machine, type your master password, carry on. No Keychain migration, no TPM binding, no "recover your account" flow. That portability is a choice, not an accident: your secrets belong to you, on hardware you control.

Open source — and you can check it does nothing sneaky

concealer is one readable Python script, MIT-licensed. No black box, no account, no telemetry. Run it behind a firewall and confirm for yourself that it never phones home — because it doesn't. That's the whole point of a local-only tool: you don't have to trust me. Read the code, watch the network.

Get started in a minute

# install (pulls in sops, age and expect)
brew install fxerkan/tap/concealer     # macOS / Linux
# or: pipx install concealer  ·  scoop install concealer (Windows)

# create the vault — prints recovery codes + a CLI token, once
concealer init

# unlock your shell session (~8h token)
eval "$(cer unlock)"

# store & use a secret — the value never touches your terminal
cer set --name OPENAI_API_KEY --project web --env prod 'sk-DUMMY-123'
cer run --project web --env prod npm run deploy

That's it. Encrypted, organized, portable — and safe to hand to an agent.

Why this matters now

We opened our codebases to models because they genuinely make us faster. I still think that was the right call. But "the assistant can read everything" and "my secrets sit in plaintext right next to my code" are two sentences that should never have been allowed to be true at the same time.

concealer is my attempt at making them coexist safely: keep the secrets encrypted, keep them local, keep them out of every transcript — and still let the agent do its job.

Stop pasting keys into chat windows. concealer will take it from there.

Links

⭐ GitHub: github.com/fxerkan/concealer
📖 Docs: concealer.fxerkan.com
🧩 Chrome Web Store: concealer extension
📦 Install: brew install fxerkan/tap/concealer · pipx install concealer · scoop install concealer

If this post was useful, a ⭐ on GitHub genuinely helps others find the project — the name collides with a makeup product, so discovery is half the battle. Questions or feedback: concealer@fxerkan.com.