/ultraplan: session creation fails with `firestore: not found` on bundle import; GitHub preflight appears to fall through to bundle path even with App installed

Resolved 💬 1 comment Opened May 18, 2026 by nathanmauro Closed Jun 17, 2026

Summary

/ultraplan consistently fails session creation in one specific repo with a firestore: not found error on seed bundle import, even after wiring up a GitHub remote and installing the Claude GitHub App on that repo. Same account, same machine, same CLI version works fine in other repos.

Error (verbatim, every attempt)

ultraplan: session creation failed — seed bundle: seed bundle import: failed to import files: error executing request: file not found: {"code":"not_found","message":"file to import not found: error retrieving file to import: firestore: not found"}

Environment

  • CLI version: 2.1.143 (native install)
  • Platform: macOS 25.4.0 (Darwin 25.4.0)
  • Repro dir: /Users/nathan/bin (private repo nathanmauro/bin)
  • Account: GitHub nathanmauro

Repro state

Tiny repo — 5 tracked files, .venv/ and .idea/ gitignored, single initial commit. Bundle content is not the trigger.

$ git ls-files | wc -l
       5
$ git log --oneline
a249fe2 Initial commit: existing scripts + claude-sessions

What I tried (in order, all reproduce identically)

  1. Initial attempt — failed.
  2. Retry — failed (not transient).
  3. git stash -u everything (mods + untracked, including an absolute symlink pointing outside the worktree) so the working tree was fully clean. Failed identically — rules out bundle content.
  4. Created private GH repo nathanmauro/bin, added git@github.com:nathanmauro/bin.git as origin, pushed main. Failed identically.
  5. Installed the Claude GitHub App on nathanmauro/bin (selected-repos install, confirmed to include this repo). Failed identically.

Hypothesis (from inspecting the bundled CLI binary)

The remote-session-create flow in H4H decides between a GitHub-source path (type: "git_repository") and a bundle path (seed_bundle_file_id). The preflight TLH(owner, name) should pass once the GitHub App has access, which would set W=true and skip the bundle entirely. But the error string seed bundle import implies seed_bundle_file_id is still being sent — i.e., W is still false despite a valid remote + App install, OR the bundle path is being taken regardless of W.

Either:

  • TLH preflight is wrongly returning false for this repo (auth/scope/staleness/per-process memoization), forcing the bundle fallback; OR
  • The bundle upload returns a fileId that the session-create endpoint cannot resolve in Firestore (upload→read inconsistency, possibly cross-region or wrong storage tier).

Likely two stacked bugs: even if the preflight bug is fixed, the bundle fallback returning an unresolvable fileId is its own defect, currently masked when the GitHub path succeeds.

Not account-wide — per-repo

/ultraplan works fine for me today from other directories (e.g. /Users/nathan/Developer/proj/claude-sessions). The discriminator looks like the git remote, not the path — claude-sessions has a GitHub remote that was already wired to the App when the preflight was first cached, while nathanmauro/bin was added to the App install only after the first failed attempt in this dir. If preflight has a per-session or per-process memo, retrying without restarting the CLI would keep failing even after the App install lands. Worth checking on your end: does a fresh claude process in this dir (after fully quitting) still fail, or only the same long-lived session?

Telemetry that would pinpoint this

  • tengu_teleport_source_decision events for my recent attempts — what was reason (github_preflight_ok / github_preflight_failed / forced_bundle / etc.)?
  • tengu_teleport_bundle_mode events — was the bundle actually uploaded and what fileId got returned?
  • Firestore lookup for that fileId — actually missing, or is the read using a different ID/path than the write?

Workarounds

None known. Local Plan agent works as a stopgap; /ultraplan does not.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗