DEV Community: day

Claude Code deletes clean worktrees on exit without asking. git worktree lock stops it.

day — Fri, 11 Sep 2026 23:12:29 +0000

TL;DR

If you /exit a claude --worktree <name> session with no uncommitted changes and no new commits, Claude Code removes the worktree and its branch without showing the Keep/Remove dialog.
This is documented behavior, not a bug. There is no setting to turn it off.
Claude Code holds its own git worktree lock on the worktree and only ever releases locks whose reason matches its own format. Re-lock the worktree with your own reason and the cleanup backs off.
A SessionStart hook can do the re-lock automatically.
Pre-creating the worktree with git worktree add does not protect it. If its branch is named worktree-<name>, existing unmerged commits get force-deleted too.

Tested on Claude Code 2.1.263, git 2.52.0, macOS.

The symptom

You start an isolated session:

claude --worktree wt-clean

You read some code, maybe run a few commands, and then /exit. You never picked "Remove worktree". But:

$ git worktree list
/path/to/demo  731024a [main]
# .claude/worktrees/wt-clean is gone, and so is branch worktree-wt-clean

If you blink you see Cleaning up worktree (no pending changes)… flash by. That's the only notice you get.

What the exit code actually checks

I pulled the bundled source out of the Claude Code binary to see the decision. On /exit from a worktree session it runs two git commands inside the worktree:

git status --porcelain                                  # changed + untracked files
git rev-list --count <HEAD at session start>..HEAD      # new commits this session

Then it branches like this:

Worktree state	Session named?	What `/exit` does
0 changed files, 0 new commits	no	Removes worktree and branch, no prompt
0 changed files, 0 new commits	yes (`/rename`)	Keep / Remove dialog
Any uncommitted change or any new commit	either	Keep / Remove dialog

The silent path runs:

git worktree unlock <path>
git worktree remove --force <path>
git branch -D worktree-<name>

The "new commits" check is relative to the HEAD at session start. Anything committed before the session doesn't count. Keep that in mind for the pre-created worktree gotcha below.

It's documented

From the official worktrees page:

The worktree is clean: for an unnamed session, Claude removes the worktree and its branch automatically. A named session prompts you first so you can keep the worktree for later

So the design intent is "clean means disposable". Plenty of people disagree. Related issues (all closed):

#27753 Worktree auto-deleted on exit when work is committed
#46444 worktree auto-cleanup permanently deleted 10 days of uncommitted project work without any warning
#58432 WorktreeRemove hook suppresses the /exit keep-or-remove picker

There is no worktree.keepOnExit-style setting. So we lean on git instead.

Why `git worktree lock` works

Claude Code already uses git worktree lock on every worktree it creates. Look at the registry while a session is running:

$ git worktree list --porcelain
worktree /path/to/demo/.claude/worktrees/wt-lock
HEAD 731024acd920b9883ae2f00845fa4ebc8ae0230e
branch refs/heads/worktree-wt-lock
locked claude session wt-lock (pid 72411 start Tue Sep  8 13:50:41 2026)

At exit, the cleanup routine reads the lock reason back and tests it against this regex (from the bundle):

/^claude (?:agent|session) .{1,255} \(pid (\d{1,10})(?: start (.{1,255}))?\)$/

If the reason doesn't match, or it matches but the PID belongs to another live process, the routine keeps the worktree and logs:

cleanupWorktree: kept <path> — locked by another live Claude Code process, or with a reason we did not write

The docs say the same thing about the background stale-lock sweep: "The sweep never releases a lock you set yourself with git worktree lock." A user-set lock is consistently treated as off-limits.

Fix 1: re-lock by hand

During the session, from another terminal (or with the ! prefix inside Claude Code):

git worktree unlock .claude/worktrees/wt-lock
git worktree lock --reason "pinned by ryan" .claude/worktrees/wt-lock

You must unlock first. Claude Code's lock is already there, so a bare lock fails:

$ git worktree lock --reason "keep" .claude/worktrees/wt-lock
fatal: '.claude/worktrees/wt-lock' is already locked, reason: claude session wt-lock (pid 72411 start ...)

Now /exit:

$ git worktree list
/path/to/demo                             731024a [main]
/path/to/demo/.claude/worktrees/wt-lock   731024a [worktree-wt-lock] locked

The reason text doesn't matter. Running git worktree unlock . && git worktree lock . from inside the worktree, with no reason at all, also kept it.

Next time, claude --worktree wt-lock drops you back into the same worktree. Your lock stays, so it survives the next /exit too.

Fix 2: automate it with a SessionStart hook

Save this script:

#!/bin/sh
# .claude/hooks/pin-worktree.sh
# Keep Claude Code from auto-removing this linked worktree on exit.
git_dir=$(git rev-parse --git-dir 2>/dev/null) || exit 0
common_dir=$(git rev-parse --git-common-dir 2>/dev/null) || exit 0
[ "$git_dir" = "$common_dir" ] && exit 0      # main worktree: nothing to pin
wt=$(git rev-parse --show-toplevel)
git worktree unlock "$wt" 2>/dev/null          # drop Claude Code's own lock
git worktree lock --reason "pinned by SessionStart hook" "$wt"

In the main worktree --git-dir and --git-common-dir are the same path, so the script is a no-op there. In a linked worktree it swaps the lock.

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          { "type": "command", "command": "sh \"$CLAUDE_PROJECT_DIR/.claude/hooks/pin-worktree.sh\"" }
        ]
      }
    ]
  }
}

Right after claude --worktree starts:

$ git worktree list --porcelain | grep locked
locked pinned by SessionStart hook

/exit leaves the worktree in place, still locked.

Where the settings file has to live

This tripped me up, so here's what I measured:

Settings location	Hook fires in the worktree session?
`.claude/settings.json` committed to the repo	yes (it's in the worktree checkout)
Untracked `.claude/settings.local.json` only in the main checkout	no (the worktree checkout doesn't have it)
A settings file outside the repo (passed with `--settings`)	yes
`~/.claude/settings.json` (user settings)	yes

The worktree session reads project settings from the worktree's own checkout. If you don't want to commit anything, put the hook in your user settings at ~/.claude/settings.json with an absolute script path. The script has no repo-specific logic, so it's safe globally.

Side note from the docs: $CLAUDE_PROJECT_DIR keeps pointing at the main checkout after Claude enters a worktree, while the hook's cwd follows the worktree. That's why the script derives the path from git rev-parse instead of the env var.

Gotchas

Pre-creating the worktree doesn't help

I assumed a worktree I made myself would be left alone. It wasn't. claude --worktree <name> adopts an existing .claude/worktrees/<name> and applies the same exit logic.

Worse: if the branch is named worktree-<name>, commits made before the session don't count as "new", so an unmerged branch gets force-deleted:

$ git worktree add -b worktree-wt-pre4 .claude/worktrees/wt-pre4
$ cd .claude/worktrees/wt-pre4 && echo precious > precious.txt && git add . && git commit -m "precious"
$ claude --worktree wt-pre4    # do nothing, /exit

$ git branch --list worktree-wt-pre4
# empty. No ref points at that commit any more.

The commit object still exists, so git fsck --lost-found can dig it out, but only if you notice. If you hand a hand-made worktree to Claude Code, lock it first.

One-off alternative: name the session

A named session always gets the dialog, even when clean:

Exiting worktree session
This session was named "keepme". Keep the worktree to resume it later, or remove it to clean up.
❯ 1. Keep worktree
  2. Remove worktree

/rename keepme then /exit is the cheapest way to keep a worktree once. You have to remember it every time, which is why I prefer the hook.

Cleaning up later

Claude Code won't touch a worktree you locked, so removal is on you:

git worktree unlock .claude/worktrees/wt-lock
git worktree remove .claude/worktrees/wt-lock
git branch -D worktree-wt-lock

Wrap-up

Claude Code's worktree cleanup is aggressive by design: clean plus unnamed equals gone. The escape hatch is already built in, just not advertised. Claude Code refuses to release a git worktree lock it didn't write, so a re-lock with your own reason, done by hand or by a SessionStart hook, is enough to keep the worktree across sessions.

Links:

Claude Code docs, worktrees: https://code.claude.com/docs/en/worktrees
Claude Code docs, hooks: https://code.claude.com/docs/en/hooks
git worktree manual: https://git-scm.com/docs/git-worktree

Turning Matt Pocock's /implement into a parallel orchestrator in Claude Code

day — Thu, 10 Sep 2026 09:22:15 +0000

I moved my Claude Code workflow from the superpowers plugin to Matt Pocock's skills. The chain /grill-with-docs → /to-spec → /to-tickets → /implement is great, but /implement is deliberately one ticket per session, with a /clear in between. Matt's own docs say batch dispatch and subagent fan-out are "requested repeatedly, and neither exists."

Meanwhile Claude Code already has everything an orchestrator needs: spawn a subagent, get its report, and send it a follow-up that resumes with its previous context intact. That is the orchestrator-subagent pattern from Anthropic's multi-agent coordination patterns post, and it maps onto Matt's tickets almost one to one.

So I kept the planning half of Matt's flow and replaced only the build half with a skill called /implement-orchestrated. Here is how it fits together.

The shape

	`/implement` (Matt)	`implement-spec` (Matt's unshipped draft)	`/implement-orchestrated`
Unit	one ticket per session	whole spec	whole spec
Parallelism	none	implementer subagents in worktrees	`coder` subagents in worktrees, up to N
Review	`/code-review` at the end	`/code-review` at the end	`reviewer` per ticket, then `code-review` + `final-reviewer`
Fix loop	same session	unspecified	SendMessage to the same coder

Four Claude Code features carry the whole thing:

Agent tool with subagent_type: implement-orchestrated:coder (the namespaced form a plugin install gives you; hand-copied into ~/.claude/agents/ it is the bare coder) and isolation: worktree
SendMessage to a finished subagent by name: it resumes from its transcript
worktree.baseRef: which commit subagent worktrees branch from
.worktreeinclude: copy gitignored files into each worktree

The loop

Read the spec and tickets. Build a state table (ticket, blockers, status, coder, branch, worktree) in a file outside the repo, because it has to survive context compaction.
Create the feature branch, record a test baseline, open a draft PR.
Dispatch the frontier (every ticket whose blockers are closed) to coder subagents, up to N at once, each in its own worktree.
When a coder reports, spawn a reviewer. On "Needs fixes", save the findings to a file and send the same coder the path. It already knows the ticket, the code, and what it did; the pointer is enough. Two failed rounds escalate to the human.
Merge with --no-ff, run the full suite, close the ticket, remove the worktree, recompute the frontier, go to 3.
At the end: Matt's code-review skill, a final-reviewer pass, push, mark the PR ready.

The brief each coder gets is three lines:

Ticket: <ticket pointer>. Spec: <spec pointer>. Notes: <notes>/notes.md (read it if it exists).

You are in your own git worktree on your own branch; every command and edit stays inside it. It holds tracked files plus any local config listed in `.worktreeinclude`, so run the project's install step (for example `npm ci`) before the first test. The glossary is `CONTEXT.md` in your worktree; if it is missing, read <main checkout>/CONTEXT.md and <main checkout>/docs/agents/. Build this ticket.

Everything else, the TDD discipline, the report format, lives in the agent definition, not in the message.

The coder agent

The old coder I had was five generic lines. Rewritten to fit Matt's tdd skill, it now carries the two ideas that skill runs on: pre-agreed seams (decide where tests go before writing any) and reporting by context pointer (branch, SHAs, test command) instead of pasting diffs.

---
name: coder
description: Use for coding tasks delegated to a subagent: implementing a ticket or spec slice, fixing a bug, refactoring, writing tests. Works test-first at pre-agreed seams and reports by context pointers. Runs on Opus 5 with max reasoning effort.
model: opus
effort: max
---

You are an implementer executing one scoped coding task from a brief. The plan was settled upstream: build what the brief says, and raise a design objection in your report rather than redesigning as you go.

## Before writing code

- Read the ticket or brief, then the code at the seams it names. When `CONTEXT.md` or `docs/adr/` exist, read the parts that touch this area: use the glossary's terms in names and tests, and flag any ADR your change would contradict.
- Seams are pre-agreed: the brief or ticket names them. When it names none, test at the public boundary where the acceptance criteria are observable, and name that boundary in your report.

## Building

- Work as one vertical slice, red → green: call the Skill tool with "mattpocock-skills:tdd" and follow its loop, one failing test then the minimal code, seam by seam. When the interface shape itself is in question, call the Skill tool with "mattpocock-skills:codebase-design".
- Typecheck often and run single test files as you go; run the full suite once at the end. Done means every acceptance criterion has a passing test at a seam, or a stated reason it cannot.
- Commit on your current branch with a message that references the ticket. Merging, pushing, and the issue tracker belong to whoever dispatched you, unless the brief says otherwise.

## Report

Your final message is the return value; the caller saw none of your tool calls. Report by context pointer: branch, worktree path, commit SHAs, the test command and its result, the seams you tested at, and anything the ticket left ambiguous. Under 200 words; the diff speaks for itself.

isolation: worktree is deliberately not in the frontmatter. The orchestrator passes it per call, so the same agent still works for a plain bug fix.

Two settings that make it work

Worktree base ref. By default a new subagent worktree branches from the remote default branch (origin/main). The orchestrator merges each finished ticket into the feature branch and then dispatches the tickets that depend on it, so with the default, ticket 03's worktree branches from origin/main and never sees ticket 01's merged code: the coder builds on stale code, or re-implements ticket 01 and conflicts at merge. With head, every worktree branches from the current tip of the feature branch:

{
  "worktree": {
    "baseRef": "head"
  }
}

Letting Claude edit ~/.claude/settings.json for you may get refused by the permission classifier (it was in my run), so run this yourself once, then start a fresh session:

python3 -c "import json;p='$HOME/.claude/settings.json';d=json.load(open(p));d.setdefault('worktree',{})['baseRef']='head';json.dump(d,open(p,'w'),ensure_ascii=False,indent=2)"

Gitignored files. A worktree holds tracked files only. My glossary (CONTEXT.md) and tracker config (docs/agents/) are gitignored, so a .worktreeinclude file (gitignore syntax) tells Claude Code to copy them into every worktree it creates:

CONTEXT.md
docs/agents/
docs/adr/
CLAUDE.local.md

List specific paths. Do not list .claude/ wholesale: .claude/worktrees/ holds your other worktrees and would be copied into every new one, recursively, gigabytes at a time. Name the subfolders you need instead (.claude/hooks/, .claude/skills/, .claude/settings.json). And the Agent tool's worktree isolation does not run your PostToolUse hooks, so .worktreeinclude is the only thing that copies untracked files into a coder's worktree.

Things that bit me

User-invoked skills can't be called by the orchestrator. Skills with disable-model-invocation: true (Matt's /implement, /to-spec) throw when called through the Skill tool. That is why the TDD discipline moved into the coder's prompt.
A plugin's agents array is not loaded. The manifest reference documents "agents": [...] in plugin.json, but on Claude Code 2.1.265 the version that declared it registered nothing (claude plugin details said Agents (0)), and the version that dropped the array and relied on the default agents/ directory registered all three (Agents (3)), namespaced.
CLAUDE_CODE_SUBAGENT_MODEL retargets every agent that does not pin a model. It sets the default model for subagents whose definition declares none, and it applies silently: with the env var set globally to opus[1m], final-reviewer — the one gate I want on the session model — started running on Opus. Any agent that must stay on the conversation's model needs model: inherit written out explicitly. That is what plugin v0.1.3 added.
The Workflow tool can't continue an agent. Each agent() call there is fresh. The "same coder, previous context" property needs Agent + SendMessage inside a skill.
Worktree cleanup. Claude Code removes a subagent worktree that finished without changes, but keeps one with unpushed commits. Coders commit, so the fix round lands in the same place.
A bare skill name is not the skill you mean. The skill called Matt's review as "code-review". That name resolves to Claude Code's own bundled code-review — and if you have a personal skill at ~/.claude/skills/code-review/, to that instead. The final gate could quietly run a review with no Spec axis while the README promised Matt's two-axis one. Every call now uses the mattpocock-skills: prefix, which fails loudly when the plugin is missing (fixed in 0.1.5 and 0.1.6).
Don't run parallel /implement sessions in one checkout. Matt's docs have a field report of one session's git commit --amend landing on another session's commit. Worktrees are the insurance.

What happened when I ran it

After publishing I ran /implement-orchestrated screenshot-source 3 on the same spec (2026-09-08, on my Chrome extension ryoshumei/add-to-calendar; the result is PR #14).

All 8 tickets closed, zero escalations. 01, 02 and 07 went out three-wide at 06:17; seven tickets were merged by 08:07. Active orchestration time was about 1h50 for tickets 01 to 07, plus about 50 minutes for the last ticket and the final gate.
The same-coder fix loop works. Ticket 07's first review came back Needs fixes (a new Deno test broke the flagless deno test invocation). One SendMessage with the path to the findings file, and the coder committed the fix (8b2a729) on the same branch in the same worktree; round two was Approved. The cwd question from the first version of this post is answered: it stayed put, three times out of three.
Two surprises. Tickets 04 and 05 touched the same files and conflicted at merge; instead of resolving in the main checkout, the orchestrator resumed 04's coder and had it merge the feature branch first. A flaky test traced back to the signed-in fixture leaving a second Supabase client alive; ticket 04's reviewer found the root cause, ticket 06 fixed it, and a maintenance ticket was logged.
What hurt most was the Claude rate limit. coder and reviewer are pinned to Opus with max effort; the eighth coder died at spawn with a 429 session limit. The orchestrator reported instead of hanging, and once allowed to continue it built that docs-only ticket itself, a logged deviation from "the orchestrator writes no feature code".
Numbers: 30 commits on the branch, +4,373 / −299 lines across 42 files. Playwright tests 27 → 89, Deno 86 → 89, final suite green. Subagent tokens about 3.24M in total (coders 1.61M, per-ticket reviewers 0.68M, final gate 0.96M).
Honest footnote: running Claude Code's built-in /code-review max on the branch afterwards produced 23 more findings, 3 of them flagged as security. They are fixed now (5 commits; the suite went 89 → 103 Playwright and 89 → 91 Deno, each finding verified by a separate reviewer), but the orchestrator's final gate should have caught them. The gap is structural rather than bad luck: that gate runs a Standards + Spec review and a whole-branch review, and neither is a correctness bug hunt.

Get it

The skill, the three agents, and install notes:

https://github.com/ryoshumei/implement-orchestrated

claude plugin marketplace add ryoshumei/implement-orchestrated
claude plugin install implement-orchestrated@ryoshumei

Requires Claude Code 2.1.263 or newer; the current plugin version is 0.1.6. Installed as a plugin the agents are namespaced (implement-orchestrated:coder, implement-orchestrated:reviewer, implement-orchestrated:final-reviewer); copied by hand into ~/.claude/agents/ they are the bare coder / reviewer / final-reviewer, and the orchestrator handles both. claude plugin details implement-orchestrated@ryoshumei should list Agents (3).

You also need Matt's plugin installed and /setup-matt-pocock-skills run once per repo; the orchestrator reads the tracker config that step writes.

Shipping an Expo app to the App Store: the landmines nobody warns you about

day — Fri, 31 Jul 2026 20:14:43 +0000

I recently shipped Add to Calendar: AI Events — an iOS app that turns screenshots and text into calendar events — built with Expo SDK 52 and React Native's new architecture. The code is open source (MIT).

The happy path in the Expo docs is genuinely good. This post is about everything that isn't on the happy path: the things that cost me hours, in the order they'll probably cost you hours too.

1. An iOS Share Extension will dominate your build config

The single hardest feature to ship was also the app's core flow: share a screenshot from any app → extension hands it to the main app → AI extracts the event. I used expo-share-intent, which is excellent, but a share extension is a second binary target, and EAS Build needs to be told about it explicitly.

Three things have to agree with each other or the build dies:

// app.json (abridged)
{
  "plugins": [
    ["expo-share-intent", {
      "disableExperimental": true,           // ← don't let the plugin manage appExtensions
      "iosActivationRules": { "NSExtensionActivationSupportsImageWithMaxCount": 1 },
      "iosAppGroupIdentifier": "group.com.addtocalendar.rn"
    }]
  ],
  "extra": {
    "eas": {
      "build": {
        "experimental": {
          "ios": {
            "appExtensions": [{               // ← you declare the target yourself, once
              "targetName": "AddtoCalendarShare",
              "bundleIdentifier": "com.addtocalendar.rn.share-extension",
              "entitlements": {
                "com.apple.security.application-groups": ["group.com.addtocalendar.rn"]
              }
            }]
          }
        }
      }
    }
  }
}

The landmine: if the plugin also injects an appExtensions entry (the default), EAS sees a duplicate and the build fails at the "Read app config" step — before compiling anything, with an error that says nothing about share extensions. disableExperimental: true plus exactly one hand-written appExtensions block was the stable combination. Once it works, commit it and never touch it.

Also budget a second provisioning profile and bundle ID (.share-extension) — EAS handles the signing, but App Store Connect will show the extension as its own "app" in some screens, which is normal and alarming in that order.

2. `patch-package` is not a code smell on mobile — it's a release valve

Two weeks after launch, users shipped me a bug: sharing a screenshot from the iOS markup editor (the pencil icon after you take a screenshot) crashed the share extension. The fix existed upstream in expo-share-intent v4 — but v4 required Expo SDK 53, and I was on 52 with a working, submitted build.

Upgrading an entire SDK to ship a five-line fix is a bad trade the week after launch. Instead:

# hand-edit node_modules/expo-share-intent/…
npx patch-package expo-share-intent
git add patches/

patch-package re-applies the diff on every npm install (via postinstall). The backported fix shipped as v1.0.2 days later, and the SDK upgrade stayed a calm, separate decision. On web I'd call vendoring a dependency a smell; on mobile, where a "dependency upgrade" can mean re-testing every native module, it's how you ship a bug fix this week instead of next month.

3. Your App Store listing should live in git

App Store Connect's web forms are where listing quality goes to die — you can't diff them, review them, or restore them. EAS Metadata fixes this and almost nobody uses it:

eas metadata:pull    # download the live listing into store.config.json
# edit store.config.json: description, keywords, release notes, screenshot sets
eas metadata:push    # upload — creates the new version's metadata in ASC

My store.config.json and screenshots are committed next to the code. Release notes are written in the same PR as the feature. When I pulled the live listing for the first time, I discovered the description had corrupted line breaks from an earlier copy-paste into the web form — it had been live like that for weeks. Listing-as-code caught what eyeballing the form never did.

Two caveats so you don't over-trust it: metadata:push does not attach a build or press "Submit for Review" — those final clicks are still manual (or fastlane/ASC API if you want to script everything).

4. The review prompt: where you call it matters more than that you call it

expo-store-review wraps SKStoreReviewController. Every guide says "throttle it." Fewer mention the two things that actually bit me:

It silently does nothing on TestFlight. By design, Apple suppresses the dialog there. If you're smoke-testing "does my rating prompt fire?", you must test a release build on a simulator/device outside TestFlight, or you'll ship believing it's broken (or worse, that it's not, when it is).

It will collide with your own dialogs. My prompt fires after a successful "event added" alert. Fire both and iOS will drop one on the floor. The fix is sequencing, not timing hacks — ask only after the user dismisses your alert:

Alert.alert('Added', `"${event.title}" added to your calendar.`, [
  { text: 'OK', onPress: () => void recordSuccessfulAddAndMaybeAskForReview() },
]);

The throttle itself: require ≥2 successful adds (proven value), ask at most once per app version, persist both in AsyncStorage, and never let the review path throw into your core flow. Apple additionally caps the system prompt at ~3 shows per year — treat requestReview() as a suggestion, not a call you own.

5. Multiline `TextInput` + a submit button = a keyboard you can't dismiss

A classic that every RN form eventually hits: a multiline input has no "done" affordance, the keyboard covers your primary button, and iOS users — who expect tap-outside-to-dismiss from native apps — get stuck. Three props, all needed:

<TextInput
  multiline
  returnKeyType="done"        // Return key says Done…
  submitBehavior="blurAndSubmit"  // …and dismisses instead of inserting \n
/>
// on the enclosing ScrollView:
keyboardDismissMode="on-drag"     // scrolling tucks the keyboard away
keyboardShouldPersistTaps="handled"

The trade-off is honest: Return no longer inserts newlines. For a paste-mostly input that's right; pasted text keeps its line breaks anyway.

6. Dark mode will look wrong in exactly one place: your modal sheets

If you build semantic colors (label, separator, grouped backgrounds) into a theme hook from day one, dark mode is nearly free — except for modals. iOS grouped backgrounds are pure black in dark mode, and a modal sheet rendered in pure black on a pure-black screen has no visible edge. Native apps solve this with elevated variants; do the same:

// in the modal screen only
const theme = {
  ...baseTheme,
  groupedBackground: baseTheme.elevatedGroupedBackground,
  card: baseTheme.elevatedCard,
};

One remap at the top of the modal, and the sheet reads as a sheet again.

7. Privacy architecture is an App Store feature, not a legal chore

The app has a bring-your-own-OpenAI-key mode. Two implementation decisions made App Review painless and became the listing's selling point:

The key lives in the iOS Keychain via expo-secure-store, is sent only to api.openai.com, and never touches my server. That sentence goes verbatim into the privacy labels, the reviewer notes, and the description — and it's true, which is what makes Guideline 2.3 (accurate metadata) easy.
Account deletion is in-app (Apple requires it if you have accounts at all — budget for it before your first submission, it's a server-side feature, not a button).

One more pre-flight item that surprises people: ITSAppUsesNonExemptEncryption: false in Info.plist saves you an export-compliance question on every single upload.

The boring meta-lesson

Every one of these was discoverable only by shipping. The gap between "runs in Expo Go" and "approved on the App Store" is real but bounded — roughly: one build-config fight (share extension), one process discovery (metadata as code), and a handful of platform behaviors (review prompt, keyboard, dark mode) that each cost an afternoon.

If you're one eas submit away and hesitating: the reviewer is not your enemy, the checklist is finite, and the second submission takes a tenth the time of the first.

The app: Add to Calendar: AI Events — screenshots/text → calendar events. Source: github.com/ryoshumei/add-to-calendar-rn. Questions about any of these landmines welcome in the comments.