DEV Community: Kaushik N

I open-sourced the start button I built for my own PC

Kaushik N — Mon, 05 Oct 2026 13:55:01 +0000

My ideas keep showing up when I'm away from my desk. On a walk, in a queue, right as I'm falling asleep. My coding sessions, on the other hand, only ever lived at the desk, on one machine, in one folder.

The hosted options can start a session from a phone, but they run in a cloud sandbox on a copy of your repo. Everything I've built up locally, the hooks, the rules, the profile, stays behind.

So three months ago I started building Claude Remote: a start button for Claude Code on my own PC. Yesterday it went public.

What it does

I open a small PWA on my phone and tap a project folder. A Claude Code session starts on the PC, in that folder, with my profile loaded and --remote-control on, so it shows up in the Claude app and I carry on there. STOP ends it.

It's deliberately not a terminal. A console on a phone screen is the wrong tool, and the Claude app already does the conversation well. The PWA only has to start things.

How it fits together

phone (PWA) --HTTPS over tailnet--> tailscale serve --> 127.0.0.1:8790 (Node agent) --> new Claude Code window

The agent is plain Node with zero runtime dependencies and binds only to 127.0.0.1. tailscale serve terminates TLS with a real certificate and forwards to it, so nothing is exposed to the internet and no firewall rule is needed.
Every /api/* route needs a token issued by a six-digit passcode. The hash is salted per install and guesses are rate-limited with a lockout. Being on the tailnet is not treated as proof it's you.
It starts at logon from a scheduled task. Updates install themselves at the next Claude Code start, restart the agent, check it actually came up, and put the previous version back if it didn't.

Three strangers changed what ships

The part I'm proudest of isn't mine.

I wrote up a Windows bug on r/PowerShell: Stop-ScheduledTask left my process running. In the comments, one person pointed out that my windowless launcher, conhost.exe --headless, swallowed exit codes and matched a technique security tools flag in attacker tooling. I measured it: exit 42 came back as 0. I'd have shipped that to every machine that installed this. Now the installer compiles a tiny launcher from source that hides the window and passes the real exit code back.

On r/Tailscale, someone mentioned their tailscale serve config disappearing after a reboot, the same thing I'd hit. Now the agent checks on every start and sends a push notification to the phone if the mapping is gone, instead of the app just saying it can't reach the PC.

All three are credited in the README, after I asked each of them.

The honest trade

A launched session runs with your user account's full permissions, and every device on your tailnet can reach the agent. On a single-user tailnet that you control, that's a reasonable trade. On a shared one it isn't. The README says this before it gives you the install command, because I'd rather lose a user than surprise one.

Try it

Windows 10/11, Node 24.2+, Tailscale and the Claude Code CLI. In Claude Code on the PC:

! npx.cmd -y github:MrTig-afk/claude-remote

It installs the plugin, sets itself up in the background and gives you a link to set a passcode.

Repo: https://github.com/MrTig-afk/claude-remote

Mac and Linux hosts come only if people ask for them in issues, so if that's you, ask.

Letting an LLM write to your database safely: previews, idempotency keys and ETags in a small FastAPI API

Kaushik N — Sat, 26 Sep 2026 00:07:28 +0000

I built NutriScan, a PWA that reads nutrition labels from a photo and tracks macros. Then I noticed I was telling Claude about my meals all day instead of logging them in my own app. So I gave the app an API, and a Model Context Protocol (MCP) connector so a claude.ai chat can read my day and log meals.

The hard part was not wiring Claude up. It was deciding what the server must guarantee regardless of what the model does. This post walks through those guarantees with the real code (FastAPI, Pydantic v2, psycopg2 on Neon Postgres with row-level security, Supabase for auth). The whole thing is open source: MrTig-afk/NutritionalTracker, mostly backend/api_v1.py.

TL;DR

Every write can run as a preview: the real code path inside a transaction that is always rolled back.
Every real POST needs an Idempotency-Key; a repeat replays the stored response for 24 h.
Every PATCH/DELETE needs If-Match with a content-hash ETag (and Cloudflare will quietly weaken it).
Errors are RFC 9457 application/problem+json with a stable error_type.
The MCP connector never lets the model save directly: write tools return a preview plus a one-time code, and only confirm_change commits, using that code as the idempotency key.
A test fails if the published OpenAPI file drifts from the code.

Status: the API and connector run on my own account while I test them; opening them up is the next phase.

The surface

17 endpoints, 8 reads and 9 writes:

Method	Path
GET	`/v1/me`, `/v1/context`, `/v1/days`, `/v1/goals`, `/v1/library`
GET	`/v1/entries/{log_id}`, `/v1/meals/{group_id}`, `/v1/templates/{template_id}`
POST	`/v1/batch`, `/v1/meals`, `/v1/entries`, `/v1/templates`, `/v1/templates/{template_id}/log`
PATCH	`/v1/entries/{log_id}`, `/v1/templates/{template_id}`
DELETE	`/v1/entries/{log_id}`, `/v1/meals/{group_id}`

And 13 MCP tools: three reads (get_context, get_template, search_library), eight write tools that only preview (log_meal, log_template, edit_entry, delete_entry, delete_meal, save_template, update_template, save_to_library), confirm_change, and stop_asking_before_saving.

1. One error shape

Before any feature, I wanted every failure to look the same. One exception type, rendered as RFC 9457 problem details, with a stable machine-readable error_type and optional extension fields:

class Problem(Exception):
    def __init__(self, status: int, error_type: str, detail: str, headers: Optional[dict] = None, **extra):
        self.status, self.error_type, self.detail = status, error_type, detail
        self.headers, self.extra = headers or {}, extra

def problem_response(p: Problem) -> JSONResponse:
    body = {"type": f"urn:nutriscan:error:{p.error_type}", "title": HTTPStatus(p.status).phrase,
            "status": p.status, "detail": p.detail, "error_type": p.error_type, **p.extra}
    return JSONResponse(jsonable_encoder(body), status_code=p.status, headers=p.headers,
                        media_type="application/problem+json")

Everything below raises Problem. A rate-limited client gets limit, used and resets_at as extension fields; an idempotency clash gets in_progress. Clients branch on error_type, humans read detail.

2. Distrust the request before you parse it

A middleware on /v1 checks size and type before a body is ever handed to Pydantic:

if request.method in ("POST", "PATCH", "PUT", "DELETE"):
    declared = request.headers.get("content-length")
    if declared is None and request.headers.get("transfer-encoding"):
        # a chunked body would be read whole before its size is known
        raise Problem(411, "length_required", "Send a Content-Length header.")
    if declared and declared.isdigit() and int(declared) > m.APP_BODY_CAP:
        raise Problem(413, "payload_too_large", "Body over 64 KB.")
    body = await request.body()
    if len(body) > m.APP_BODY_CAP:
        raise Problem(413, "payload_too_large", "Body over 64 KB.")
    ctype = request.headers.get("content-type", "").split(";")[0].strip().lower()
    if body and ctype != "application/json":
        raise Problem(415, "unsupported_media_type", "Send JSON with Content-Type: application/json.")

Note the declared length is checked and the real length, because a header can lie.

Then the models are strict. Unknown fields are an error, not silently dropped, and every number and string is bounded:

Name = Annotated[str, Field(min_length=1, max_length=80), AfterValidator(_text)]
Servings = Annotated[float, Field(gt=0, le=100)]
LogDate = Annotated[str, Field(pattern=r"^\d{4}-\d{2}-\d{2}$"), AfterValidator(_log_date)]

class Strict(BaseModel):
    model_config = ConfigDict(extra="forbid")

class Macros(Strict):
    calories: float = Field(ge=0, le=MAX_KCAL)
    protein_g: float = Field(ge=0, le=1000)
    # ...
    sodium_mg: Optional[float] = Field(None, ge=0, le=100000)

class Item(Strict):
    name: Name
    portion: Optional[Portion] = None
    servings: Servings = 1
    macros: Macros
    save_to_library: bool = False

_text strips control characters and _log_date refuses dates more than a day in the future. extra="forbid" matters more than it looks when the client is an LLM: a hallucinated field like "meal_type": "brunch" fails loudly instead of being ignored while the model believes it was saved.

3. Tokens that never wake the database for a guess

Personal tokens look like nsk_live_ plus 43 URL-safe characters (secrets.token_urlsafe(32)). They are shown once and only their sha256 is stored:

TOKEN_PREFIX = "nsk_live_"
_TOKEN_RE = re.compile(r"^nsk_live_[A-Za-z0-9_-]{43}$")
MAX_TOKENS = 10
EXPIRY_DAYS = {"30d": 30, "90d": 90, "1y": 365, "never": None}

def token_hash(token: str) -> str:
    return hashlib.sha256(token.encode()).hexdigest()

The database is serverless and bills for time awake, so a bot spraying random tokens should not be able to keep it up. At startup the server loads the first 12 characters of every live token into a set, and a token whose prefix is not in it is refused without a query:

if token.startswith(TOKEN_PREFIX):
    known = _live_prefixes is None or token[:12] in _live_prefixes
    row = _TOKEN_RE.match(token) and known and _lookup_token(token_hash(token), request.headers.get("user-agent"))

Valid lookups are cached for 300 seconds. And guessing is punished: the 20th bad token from one IP inside five minutes blocks that IP for ten minutes.

if not row:
    ip = m._client_ip(request)
    if m._spike(f"patfail:{ip}", 20, 300):
        m._blocked[ip] = time.time() + 600
    raise Problem(401, "unauthorized", "Invalid token.")

Scopes are a FastAPI dependency per route, and write routes re-check scopes per change inside a batch:

def need(*scopes: str, write: bool = False):
    def dep(request: Request) -> Caller:
        budget_gate()
        caller = resolve_caller(request)
        _require(caller, *scopes)
        request.state.ratelimit = take_request(caller, write)
        # ...

4. Rate limits a client can plan around

Limits are per user across all their tokens: 20 requests a minute, 10 writes a minute, 200 a day, with the day resetting at Melbourne midnight (where the app's users are). Every answer carries RateLimit-* headers, and a 429 says exactly when to come back:

BURST_PER_MIN, WRITES_PER_MIN, DAILY_CAP = 20, 10, 200
MELBOURNE = ZoneInfo("Australia/Melbourne")
# ...
retry = max(1, int(resets.timestamp() - now) + 1)
raise Problem(429, "rate_limited", f"Over the limit of {limit}. Try again after {_zulu(resets)}.",
              headers={"Retry-After": str(retry), "RateLimit-Limit": str(limit), "RateLimit-Remaining": "0"},
              limit=limit, used=used, resets_at=_zulu(resets))

Honest wrinkle: on a successful response RateLimit-Limit always reports the daily cap, not whichever per-minute window is closest. The 429 is precise; the happy-path headers are a simplification.

5. Previews by rollback

This is the core idea. A preview should not estimate what a write would do; it should do it and throw the result away. So every write handler runs inside one database helper, and preview just turns off the commit:

@contextmanager
def db(user_id: Optional[str], commit: bool = True):
    conn = None
    try:
        conn = m.get_db(user_id)
        cur = conn.cursor()
        yield cur
        if commit:
            conn.commit()
        cur.close()
    # ...

with db(caller.user_id, commit=not preview) as cur:
    ...  # the exact same writes, triggers, RLS policies and validation

When the connection goes back to the pool, release_db always calls conn.rollback() (it also resets the transaction-local app.user_id setting that the RLS policies read), so an uncommitted preview leaves nothing behind.

Because it is the same code path, the preview includes things an estimate would miss: database defaults, trigger side effects, constraint violations. Any /v1 write accepts ?preview=true.

To be precise about what is tested: the tests assert that a preview produces zero commits and the real call exactly one. There is no test yet that diffs the preview body against the committed body; the equivalence comes from sharing the code path, not from an assertion.

6. Idempotency keys

A real POST must carry an Idempotency-Key header. The key, a hash of the request, and eventually the response are stored in the same transaction as the write:

if not preview and request.method == "POST":
    key = (idempotency_key or "").strip()
    if not key or len(key) > 255:
        raise Problem(422, "validation_error", "Idempotency-Key header required (1-255 characters) on a real write.")
rhash = _request_hash(request.url.path, payload)
with db(caller.user_id, commit=not preview) as cur:
    if key:
        cur.execute("DELETE FROM api_idempotency WHERE user_id = %s AND key = %s "
                    "AND created_at < now() - interval '24 hours'", ...)
        cur.execute("""INSERT INTO api_idempotency (user_id, key, request_hash, status_code, response)
                       VALUES (%s, %s, %s, 0, '{}') ON CONFLICT (user_id, key) DO NOTHING RETURNING 1""", ...)
        if not cur.fetchone():
            old = ...  # the stored row
            if old[0] != rhash:
                raise Problem(409, "idempotency_conflict", "This Idempotency-Key was used for a different request.")
            if not old[1]:
                raise Problem(409, "idempotency_conflict", "A request with this Idempotency-Key is still running.",
                              in_progress=True)
            replay = (old[1], old[2])

Three cases fall out of the INSERT ... ON CONFLICT DO NOTHING RETURNING 1:

New key: the placeholder row is claimed, the write runs, the response is stored.
Same key, same request: the stored status and body are replayed.
Same key, different request (the hash is sha256 of path plus payload with sorted keys): 409, because silently replaying a different request is worse than failing.

A status of 0 marks "claimed but not finished", which is how a concurrent duplicate gets in_progress: true instead of a second insert. The test that pins it:

def test_same_key_twice_gives_one_set_of_rows(self):
    body = {"date": TODAY, "name": "Apple", "macros": MACROS}
    first = self.post("/v1/entries", body)
    second = self.post("/v1/entries", body)
    self.assertEqual(second.json()["entry"]["log_id"], first.json()["entry"]["log_id"])
    self.assertEqual(len(self.statements("INSERT INTO daily_log")), 1)

7. ETags, If-Match, and the proxy that rewrote them

Edits and deletes use optimistic concurrency. The ETag is a hash of the content itself, so no version column is needed:

def etag_of(*parts) -> str:
    return '"' + hashlib.sha256(json.dumps(parts, sort_keys=True, default=str).encode()).hexdigest()[:16] + '"'

def update_entry(self, c: UpdateEntryChange):
    log_id, name, servings, nutrition, d = self.entry(c.log_id)
    n = log_service.load_nutrition(nutrition)
    if etag_of(name, servings, n, str(d)) != c.if_match:
        raise Problem(412, "precondition_failed", "The entry changed since you read it. Read it again.")

This worked perfectly on my machine and failed on every edit in production. The backend sits behind Cloudflare, and when Cloudflare compresses a response it weakens the ETag to W/"...". Clients faithfully echoed back the weak form, which never matched. The fix:

def _if_match(value: Optional[str]) -> str:
    if not value:
        raise Problem(422, "validation_error", "If-Match header required: send the ETag you read.",
                      errors=[{"field": "If-Match", "message": "required"}])
    # Cloudflare weakens ETag to W/"..." when it compresses a response
    return value.strip().removeprefix("W/")

Strictly, RFC 9110 says If-Match uses strong comparison, so a weak tag should never match. Here the ETag is a hash of content I generate myself, and the only thing that weakens it is my own proxy, so accepting the stripped form is safe. It is a deliberate deviation, commented where it lives. (A missing If-Match returns 422; 428 Precondition Required would arguably be the more precise status.)

8. An API that switches itself off before the bill

The database runs on a free monthly compute allowance. The app estimates its own usage, and at 90% the API pauses while the app itself keeps working:

def budget_gate():
    """At 90% of the estimated free Neon month, /v1 pauses; the app keeps working."""
    if m.budget_used() >= 0.9:
        resume = m.neon_next_period_start(datetime.now(timezone.utc).date())
        retry = int(datetime(resume.year, resume.month, resume.day, tzinfo=timezone.utc).timestamp() - time.time())
        raise Problem(503, "api_paused_budget", f"The API is paused to protect the database budget until {resume.isoformat()}.",
                      headers={"Retry-After": str(max(retry, 1))}, resets_at=f"{resume.isoformat()}T00:00:00Z")

On /v1 it runs in the need() dependency before anything else. On /mcp it only gates tools/call, so initialize and tools/list still answer and Claude sees a tool error rather than a dead server.

9. The MCP connector: the model never saves directly

Auth

The connector uses Supabase's OAuth 2.1 server. Claude discovers it from the protected-resource metadata, and every unauthenticated call gets a challenge pointing there, which is what makes claude.ai (re)start the OAuth flow:

@mcp_router.get("/.well-known/oauth-protected-resource/mcp")
@mcp_router.get("/.well-known/oauth-protected-resource")
def protected_resource() -> dict:
    return {"resource": MCP_URL, "authorization_servers": [mcp_issuer()], "scopes_supported": ["email"],
            "bearer_methods_supported": ["header"], "resource_name": "NutriScan"}

def _mcp_challenge() -> Problem:
    return Problem(401, "unauthorized", "Connect through claude.ai to use NutriScan.",
                   headers={"WWW-Authenticate": f'Bearer resource_metadata="{MCP_PRM_URL}"'})

A token is accepted only if it has a client_id, the right issuer and the authenticated audience. A personal token or a normal app login gets the challenge, not access.

One subtle ordering bug I hit: if /mcp declared a typed JSON body, FastAPI would validate it first and a tokenless probe would get a 422 instead of the 401 challenge, so discovery never started. So the route reads the raw body and parses it only after the origin allowlist and auth:

@mcp_router.api_route("/mcp", methods=["GET", "POST", "DELETE"])
async def mcp(request: Request):
    # parsed only after the origin and auth checks: a declared JSON body would 422 before them
    raw = await request.body()
    return await run_in_threadpool(_mcp, request, raw)

def _mcp(request: Request, raw: bytes):
    origin = request.headers.get("origin")
    if origin and origin not in MCP_ORIGINS:   # ("https://claude.ai", "https://claude.com")
        raise Problem(403, "forbidden_origin", "This origin may not call /mcp.")
    caller, client_id = mcp_caller(request)
    # ... only now: payload = json.loads(raw)

Preview, one-time code, confirm

Every write tool calls the same run_changes as /v1, with preview=True. The result goes back to the model with a one-time code:

PENDING_TTL, PENDING_MAX = 600, 20

_, body = run_changes(request, caller, [change], True, None)
code, now = secrets.token_urlsafe(16), time.time()
with _pending_lock:
    for k in [k for k, v in _pending.items() if now - v[3] > PENDING_TTL]:
        del _pending[k]
    mine = sorted((v[3], k) for k, v in _pending.items() if v[0] == caller.user_id)
    for _, k in mine[:max(0, len(mine) - PENDING_MAX + 1)]:
        del _pending[k]
    _pending[code] = (caller.user_id, client_id, [change], now, guard)
return json.dumps({"preview": jsonable_encoder(body), "confirm_code": code,
                   "expires_in_minutes": 10, "next": NEXT_STEP}, default=str)

The model shows the preview to the user. Only confirm_change writes, and it reuses the code as the idempotency key, so a retried confirm replays instead of inserting twice:

entry = _pending.get(code) if isinstance(code, str) else None
if (not entry or entry[0] != caller.user_id or entry[1] != client_id
        or time.time() - entry[3] > PENDING_TTL):
    raise Problem(422, "confirmation_invalid", "This confirmation expired or is not valid. Ask again.")
if entry[4] and _template_etag(caller, entry[2][0].template_id) != entry[4]:
    raise Problem(412, "precondition_failed", "This changed since the preview. Ask again.")
_, body = run_changes(request, caller, entry[2], False, code)   # the code is the idempotency key

The code is bound to the user and the OAuth client, expires in ten minutes, and at most 20 are pending per user (oldest evicted). The guard covers the one change type that carries no If-Match (logging a template), so editing the template between preview and confirm is caught too.

def test_retry_replays_instead_of_saving_twice(self):
    code = self.preview()
    self.conn.executed.clear()   # the preview ran (and rolled back) its own INSERT
    first = self.confirm(code)
    second = self.confirm(code)   # e.g. the first answer was lost and claude.ai retried
    self.assertEqual(json.loads(second[1]), json.loads(first[1]))
    self.assertEqual(len(self.statements("INSERT INTO daily_log")), 1)

Tool annotations

Since a preview cannot save anything, there is no reason for the client to ask permission before one. Only the tool that actually commits is marked destructive, so the user gets one prompt, for the save:

def _annotations(name: str) -> dict:
    saves = name == "confirm_change"
    return {"readOnlyHint": not saves, "destructiveHint": saves, "idempotentHint": False, "openWorldHint": False}

(stop_asking_before_saving, which turns off one setting, is hand-annotated as not read-only but not destructive.)

The rule behind all of this: the guarantees live in the server, not in the prompt. Tool descriptions tell Claude to show the preview and wait, and it does. But if it did not, a write without a valid code is still not a write.

10. Documentation that cannot drift

The OpenAPI document is generated from the code and also committed as openapi-v1.json. A test fails if they differ, and pins the route count:

def test_published_openapi_matches_the_code(self):
    path = os.path.join(os.path.dirname(os.path.abspath(__file__)), "..", "openapi-v1.json")
    with open(path, encoding="utf-8") as f:
        published = json.load(f)
    self.assertEqual(published, json.loads(json.dumps(api_v1.openapi_v1())),
                     "regenerate backend/openapi-v1.json from api_v1.openapi_v1()")
    routes = sum(len(ops) for ops in published["paths"].values())
    self.assertEqual(routes, 17)

Known ceilings

This runs as a single instance on a small host, and some choices only hold there:

Rate-limit windows and pending confirm codes live in process memory. A restart forgets pending codes (the user just asks again), and a second instance would need Redis or a table.
The token-prefix set is loaded at startup and updated by the create endpoint, so a token inserted straight into the database is refused until a restart.
Preview equivalence is guaranteed by the shared code path, not yet by a test that diffs bodies.

Wrap-up

None of these patterns are new: Stripe popularised idempotency keys, ETags are older than most of us, and RFC 9457 exists so we stop inventing error formats. What was new to me was how much they matter once the client is a language model. An LLM retries, guesses field names and acts confidently on stale reads. Every one of those is a problem a boring HTTP mechanism already solves, as long as the server enforces it.

Questions, or things you would have done differently? I would genuinely like to hear them in the comments.

Tailscale said Connected. My app said it couldn't reach my PC. They were both right

Kaushik N — Tue, 22 Sep 2026 06:09:03 +0000

My app is a small web app on my phone that starts Claude Code sessions on my Windows PC. The phone reaches the PC over Tailscale: tailscale serve gives the PC an HTTPS address on my private network and forwards requests to a Node server listening only on 127.0.0.1.

It had worked for weeks. Then, in one afternoon, it broke three different ways, and every one of them looked like a bug in my app. None of them were.

Break 1: "Cannot reach the agent"

The phone app opened, asked for my passcode, and told me to keep retrying.

The server was fine. It answered locally in two milliseconds. So I asked Tailscale what it was forwarding:

> tailscale serve status
No serve config

The forwarding had quietly disappeared. I never found out why. --bg is meant to survive reboots. Turning it back on was one line:

tailscale serve --bg --https=8790 8790

The phone connected straight away.

Break 2: a white screen, then "the server stopped responding"

Next I added the app to my home screen, from Safari and from Chrome. Both opened to a blank white page for a minute or two, then Safari gave up: the server stopped responding.

A browser tab on the same phone worked. That made it look like a home-screen app problem, and I nearly went digging into service workers.

The clue was in my own terminal. Right after turning serve back on, my first test request from the PC had timed out, and the second one came back in 26 milliseconds. Tailscale issues the HTTPS certificate on the first connection after serve is enabled, and that connection can take tens of seconds. The home-screen apps had hit that window.

By the time I'd set up a way to watch it, the window had passed and both apps loaded fine. So this one is my best explanation rather than a proof. But the fix costs nothing either way: my setup script now makes one request itself, right after enabling serve, before it hands you the link. The script waits for the certificate, not your phone.

Break 3: "Waiting for the PC", while Tailscale said Connected

An hour later the app hung on its lock screen: Waiting for the PC. The Tailscale app on the phone said Connected. The server was up. The HTTPS address answered from the PC in 30 milliseconds.

I'd been guessing for long enough. I needed to see what the phone actually sent. Tailscale keeps no request log I could read, so I put a recorder in the middle: a tiny Node relay between tailscale serve and my server, logging when each request starts and when it finishes.

http.createServer((req, res) => {
  const id = ++n, t0 = Date.now();
  log(`#${id} > ${req.method} ${req.url.split('?')[0]}`);
  const up = http.request({ host: '127.0.0.1', port: 8790, method: req.method,
                            path: req.url, headers: req.headers }, (ur) => {
    res.writeHead(ur.statusCode, ur.headers);
    ur.pipe(res);
    ur.on('end', () => log(`#${id} < ${ur.statusCode} ${Date.now() - t0}ms`));
  });
  req.on('aborted', () => log(`#${id} ! client aborted`));
  req.pipe(up);
}).listen(8792, '127.0.0.1');

Then I pointed serve at the relay instead of the server. The phone keeps the same address, so nothing changes on its side:

tailscale serve --bg --https=8790 http://127.0.0.1:8792

(It deliberately logs only the method and path. Headers carry the session token, and a debugging log is the last place that should end up.)

The log settled it in one screen. The phone fetched every file of the app, and each was answered in under 50 milliseconds. Then it made the call that checks the passcode, /api/auth/status, and that request never arrived. Not once, across 45 seconds of retries.

So the tunnel worked for some requests and not others. From the PC, a Tailscale ping to the phone had one timeout, then a 560 ms reply, where it had been 17 ms that morning. And when I asked what the phone's Tailscale app itself said, it had a warning: magicsock is not running. That's the part of Tailscale that actually moves your traffic.

Fully quitting and reopening the Tailscale app fixed it. Seconds later the log showed the passcode check arrive, then the unlock, then my project list.

What I changed

The setup script now warms the certificate itself before handing over the link.
The README has an FAQ entry for this exact state: stuck on Waiting for the PC or Can't reach your PC while Tailscale says Connected means quit and reopen Tailscale on the phone.
The relay went back in a drawer. It took about a minute to put in and a minute to take out, which is the right price for a tool you only need on a bad day.

What I took away

"Connected" is a status, not proof that traffic is moving. Measure the thing you actually care about.
When two sides disagree, put a recorder at the boundary before touching either side. One screen of log beat an hour of theories.
The first request after turning on HTTPS pays for the certificate. Make your own tooling pay it, not your users.

This is part of Claude Remote, which starts Claude Code on your own Windows PC from your phone. The repo goes publi

iOS zoomed my app in and never zoomed back out. So I stopped grepping CSS and asked the browser

Kaushik N — Fri, 18 Sep 2026 12:52:02 +0000

I was naming a new project in my app, on my iPhone. I tapped the text box, and the whole page zoomed in. The header was cut off on both sides. I finished typing, tapped away, and it stayed zoomed.

If you've built anything for phones, you might already know this one: iOS Safari zooms the page in when you focus a text input whose font is smaller than 16px, and it does not zoom back out. The fix is one line of CSS. Keeping it fixed is the hard part, because any later rule that shrinks an input brings the bug straight back, and nothing looks wrong on a desktop.

So I wanted a test that fails the moment any text input drops below 16px.

Attempt one: read the CSS

My first version read app.css with regular expressions and looked for font sizes on input selectors. It seemed simple. Over three rounds of review it turned out to have six holes, and two of them came from my own attempts to harden it:

Stripping out @media blocks swallowed the rule that came after them.
A 16px floor inside a media query was read as if it applied everywhere.
A CSS custom property looked like it won over the real declaration.
Selectors like .dense.pin and :is(.pin) slipped past the class match.

Every fix made the parser a bit smarter and a bit more wrong. The real problem was the approach. A regex can't do the cascade, specificity or inheritance, and all three decide what font size an input actually gets.

The browser already does all three. So I asked it.

Attempt two: ask the browser

The new check starts headless Chrome, loads my app, and asks for the computed font size of every input:

[...document.querySelectorAll('input, textarea, select')].map((el) => {
  const cs = getComputedStyle(el);
  return {
    id: el.id || null,
    type: el.getAttribute('type') || el.tagName.toLowerCase(),
    computedFontSizePx: parseFloat(cs.fontSize),
  };
});

It skips checkboxes, radio buttons and other inputs you can't type into, because iOS never zooms for those. Anything left under 16px fails the test.

Three details mattered more than I expected.

It needs zero dependencies. My app has none, and the PC it runs on has 8GB of RAM, so I didn't want Playwright or Puppeteer just for this. Node 22 and later ship a WebSocket built in, and that's all you need to speak the Chrome DevTools Protocol. Chrome is launched with --headless=new --remote-debugging-port=0, the check reads the port Chrome picked from the DevToolsActivePort file, and it sends Runtime.evaluate over the socket.

It serves the files over HTTP, not file://. My index.html links /app.css with an absolute path. Under file:// that points at the root of the drive, so the stylesheet never loads and every input reads back at the browser's default size. That's a false failure today. Worse, it becomes a false pass the day someone removes the 16px rule. So the check runs a tiny throwaway server on a random port.

It measures at a phone size too. Headless Chrome starts at 800 by 600, so a rule inside @media (max-width: 430px) never applies there. A phone breakpoint is exactly where an input is most likely to get shrunk, and review caught that my first browser version never saw it. Now the check measures at 1280 by 900 and again at 390 by 844 in mobile mode.

A test that can't fail isn't a test

A check like this can quietly pass forever while checking nothing. So the suite proves it can fail. It copies the app into a temp folder, adds one line to the stylesheet copy, and expects exactly that input to be caught:

fs.appendFileSync(
  path.join(tmp, 'app.css'),
  '\n.newproj-panel input { font-size: 12px; }\n',
);
// ...
assert.equal(report.textInputsBelow16[0].id, 'newproj-name');
assert.equal(report.textInputsBelow16[0].computedFontSizePx, 12);

A second test does the same thing inside a phone-sized @media block. Both work on a copy, because node --test runs files in parallel and another test reads the real stylesheet.

A skipped guard is a green run

The last decision was what to do when Chrome isn't installed.

Skipping looked polite. But node --test exits 0 when a test is skipped. On a machine without Chrome, the only check that can catch this bug would vanish, and the run would still report every test passing.

So it fails by default. If you really can't run it, you have to say so out loud with ALLOW_NO_CHROME=1, and the skip message says what's now unchecked.

That rule caught me this week, on my own PC. My Chrome is a per-user install, which the lookup doesn't search yet, so the suite went red until I pointed CHROME at it. Mildly annoying. It's exactly what I asked it to do.

What I took away

If a tool already answers the question, ask the tool. The browser knows what font size an input ends up with. My regex was guessing.
Prove every guard can fail, against a copy, before trusting it when it passes.
Treat a skip as a failure unless someone typed the opt-out.

This is part of Claude Remote, a small app I'm building that starts Claude Code sessions on my own Windows PC from my phone. It isn't public yet.

If you want to follow along: https://github.com/MrTig-afk

The cloud can have my code. It can't have my Claude.

Kaushik N — Wed, 16 Sep 2026 13:46:01 +0000

The Claude app can start a coding session from your phone. It spins up a cloud sandbox, clones your GitHub repo into it, and lets you work from anywhere. For a lot of people, that's everything they need.

It wasn't enough for me, and the reason turned into a project.

The setup that can't travel

Over the last few months I've customised Claude Code heavily. None of it is exotic, but it adds up:

Hooks: scripts that run automatically on events. Mine refuse a commit until the review steps have actually run.
Skills: written instructions for how I plan, review, test and ship.
A global CLAUDE.md: the rules I want followed in every project, rewritten every time something goes wrong.

All of that lives in my profile folder, not in any repository. I keep it out of GitHub on purpose, because it describes how I work and what I'm building.

A cloud sandbox gets a clone of my repo and stock Claude Code. Same model, much worse assistant. That's the whole pitch in one line: the cloud can have my code, but it can't have my Claude.

Claude Code's Remote Control already lets me continue a session on my PC from my phone. But someone has to start that session at the desk first. I wanted to start one from my phone, in whichever project I pick, with my whole setup loaded.

What I built

Claude Remote is a Claude Code plugin. Fittingly, it installs into the same setup it exists to protect. You add its marketplace and install it from inside Claude Code, with no separate download and no cloning. If you want to change how it works, you fork it.

Under the hood it's two small pieces:

A Node agent on my Windows PC. It has zero dependencies, runs as a scheduled task, and listens only on loopback.
A PWA on my phone. It lists my projects, starts a session when I tap one, and stops it when I tap stop.

The phone reaches the agent through tailscale serve, so it only works inside my private Tailscale network. There are no open ports, and every API call needs a token issued by a passcode. When I tap a project, a PowerShell launcher changes into that folder, activates its environment, and runs Claude Code with Remote Control on. The session appears in the Claude app's Code tab, and I drive it from there.

The PWA is deliberately not a terminal. It's a start button. The conversation happens in the Claude app, which already does that well.

One touch I like: if the project has a HANDOFF.md, a notes file I keep for where the work stands, the launcher passes a first prompt:

Read HANDOFF.md and give the opening report.

A session I start away from my desk opens by telling me where things are, instead of sitting silent waiting for input.

That created its own problem. A session could now start itself and begin working with nobody watching. So the opening report has to end as a proposal and wait for my go. The first thing I hear from a session should never be work that's already underway.

Four bugs that passed every test

The code was the easy part. What took the time was a series of bugs that looked fine from every angle a test could see.

1. One flag silently broke Remote Control

My desk setup launches Claude Code with a --channels flag for a messaging plugin. I carried it over to the launcher.

The session started perfectly. Right window title, interface drawn, ready to work. But Remote Control sat on "connecting" forever, and the session never appeared in the Code tab. From the phone, it looked like nothing had happened.

Removing that one flag fixed it in seconds. Two experimental input channels were competing for the same session.

No test could have caught this. The process was healthy, and the only symptom was a row missing from an app on my phone. It took a person looking at the screen. Now, any change to the launch arguments means checking the app again, by hand.

2. A reviewer's fix would have broken every Python project

To activate a Python virtual environment, the launcher adds the venv's Scripts folder to the front of PATH. A review pointed out that a ; in the project path would split that entry, and suggested quoting it.

Sensible advice, but wrong here. PowerShell's command resolution doesn't honour quotes inside a PATH entry. With the quoted version, python resolved to the system interpreter, while VIRTUAL_ENV claimed the venv was active. Every venv project would have launched outside its venv, and nothing would have looked wrong.

The whole test suite stayed green, because the tests used a synthetic venv. They proved python.exe existed in the right place, never that it resolved. I only caught it by running the real launcher against a real venv and asking which python came back.

A ; in the path is now refused with a clear message instead of quoted around.

3. `conda activate` failing doesn't throw

For conda projects, the launcher reads the environment name from environment.yml and runs conda activate. I wrapped it in a try/catch.

That catches nothing useful. In PowerShell, a native command exiting non-zero isn't an exception, even with $ErrorActionPreference = 'Stop'. When the environment doesn't exist, which is the most likely failure, conda prints an error and carries on. A cloned repo naming an environment you don't have would have launched a healthy-looking session sitting in base.

The fix checks the result, not the exception. After activating, the launcher compares CONDA_DEFAULT_ENV against the name it asked for, and refuses the launch if they differ. The try/catch stays too, because a command-resolution failure does throw. That distinction is the entire guard.

4. Activating a venv let a repo choose which Claude to run

Adding the venv's Scripts folder to PATH had a second consequence. The launcher started Claude Code by name, so the name was looked up through the new PATH. A cloned repo carrying its own claude.cmd in its venv would have had that file run instead, with my full user permissions, the moment I tapped the project.

The fix resolves Claude Code to an absolute path before the venv touches PATH, so the project never gets a say in which executable starts.

The state I deleted

Early on, a broken environment didn't stop the launch. The launcher recorded the error and started the session anyway, reasoning that a running session was better than none.

That produced a session that was alive and wrong at the same time. I designed five different ways to show "running, but in the wrong environment" on a phone screen, and every one was confusing. A condition that persists doesn't fit in the same banner as a one-off message.

In the end I deleted the state. A broken environment now stops the launch, and the phone shows why. A clear failure beats a session that quietly works in the wrong place.

What I took away

Green tests prove what the tests can see. Three of these four bugs lived at a layer the tests never touched: a phone screen, command resolution, an exit code.
Run the real thing. A synthetic fixture proves a file exists. Only the real launcher proves it works.
Alive but wrong is worse than failed. If the tool can't do the job properly, it should say so and stop.

Claude Remote is Windows only and not public yet. When it is, it will be a plugin you can install from inside Claude Code, and a repo you can fork if you want it to work differently. Until then, if you keep your Claude Code setup out of your repos too, I'd like to hear how you use it away from your desk.

If you want to follow along, I'm on GitHub: https://github.com/MrTig-afk

DEV Community: Kaushik N

I open-sourced the start button I built for my own PC

What it does

How it fits together

Three strangers changed what ships

The honest trade

Try it

Letting an LLM write to your database safely: previews, idempotency keys and ETags in a small FastAPI API

The surface

1. One error shape

2. Distrust the request before you parse it

3. Tokens that never wake the database for a guess

4. Rate limits a client can plan around

5. Previews by rollback

6. Idempotency keys

7. ETags, If-Match, and the proxy that rewrote them

8. An API that switches itself off before the bill

9. The MCP connector: the model never saves directly

Auth

Preview, one-time code, confirm

Tool annotations

10. Documentation that cannot drift

Known ceilings

Wrap-up

Tailscale said Connected. My app said it couldn't reach my PC. They were both right

Break 1: "Cannot reach the agent"

Break 2: a white screen, then "the server stopped responding"

Break 3: "Waiting for the PC", while Tailscale said Connected

What I changed

What I took away

iOS zoomed my app in and never zoomed back out. So I stopped grepping CSS and asked the browser

Attempt one: read the CSS

Attempt two: ask the browser

A test that can't fail isn't a test

A skipped guard is a green run

What I took away

The cloud can have my code. It can't have my Claude.

The setup that can't travel

What I built

Four bugs that passed every test

1. One flag silently broke Remote Control

2. A reviewer's fix would have broken every Python project

3. conda activate failing doesn't throw

4. Activating a venv let a repo choose which Claude to run

The state I deleted

What I took away

3. `conda activate` failing doesn't throw