@.github/workflows/release-cli.yml release seems to be failing

Let me investigate the CLI build setup and check for recent workflow run failures.

All 5 recent runs have failed. Let me check the latest failure details.

Let me also check if earlier runs had different failures.

Found the issues. There are two problems:

1. HOMEBREW_TAP_TOKEN secret is not set (current failure)

The logs show HOMEBREW_TAP_TOKEN: is empty. GitHub Actions would mask it as *** if it were set. The git push fails with:

remote: Invalid username or token. Password authentication is not supported for Git operations.

You need to create a GitHub Personal Access Token (classic) with repo scope for the JustinyAhin/homebrew-threadcast repo and add it as a secret named HOMEBREW_TAP_TOKEN in the threadcast repo settings.

2. Binary name mismatch in Homebrew formula (latent bug)

The tar archives contain files named threadcast-darwin-arm64, threadcast-linux-x64, etc. But the formula does:

def install
  bin.install "threadcast"   # looks for a file named "threadcast"
end

This will fail at brew install time because there's no file called threadcast inside the archive — it's called threadcast-darwin-arm64 (etc.).

Fix — rename the binary to threadcast before creating the tar.gz:

Now fix issue 1 — set the HOMEBREW_TAP_TOKEN secret. You'll need to:

1. Go to github.com/JustinyAhin/threadcast → Settings → Secrets and variables → Actions
2. Add a repository secret named HOMEBREW_TAP_TOKEN with a Personal Access Token (classic) that has repo scope and access to JustinyAhin/homebrew-threadcast

The binary naming fix is committed locally and ready to push when you're ready.

1. Go to github.com → click your profile picture → Settings
2. Scroll down the left sidebar → Developer settings
3. Personal access tokens → Tokens (classic)
4. Click Generate new token → Generate new token (classic)
5. Give it a name like homebrew-tap
6. Set an expiration (or no expiration)
7. Check the repo scope (full control of private repositories)
8. Click Generate token
9. Copy the token immediately (you won't see it again)

Then add it as a secret:

1. Go to github.com/JustinyAhin/threadcast → Settings → Secrets and variables → Actions
2. Click New repository secret
3. Name: HOMEBREW_TAP_TOKEN
4. Value: paste the token
5. Click Add secret

You're right, fine-grained is the better choice here. I defaulted to classic out of habit, but fine-grained lets you scope it tighter.

With a fine-grained token:

1. Set Resource owner to JustinyAhin
2. Repository access → Only select repositories → pick homebrew-threadcast
3. Permissions → Repository permissions → Contents: Read and write
4. That's it — no other permissions needed

This is more secure since it only grants write access to that one repo instead of all repos under your account.

Yes, that's fine. The HOMEBREW_TAP_TOKEN is only used to clone and push to homebrew-threadcast. It doesn't need access to threadcast itself.

The workflow already uses ${{ github.token }} (line 77) for downloading release assets from the private threadcast repo — that's provided automatically by GitHub Actions.

Once you've set the secret and run the release workflow successfully:

brew tap JustinyAhin/threadcast
brew install threadcast

If you want to install it right now without waiting for the release, you can build locally:

bun run --filter @threadcast/cli build

Then copy the binary from packages/cli/dist/threadcast-darwin-arm64 to somewhere on your PATH:

cp packages/cli/dist/threadcast-darwin-arm64 /usr/local/bin/threadcast

Release looks good! All 8 assets (4 raw binaries + 4 tar.gz archives) are there and the workflow passed (green checkmark).

You should now be able to install via Homebrew:

brew tap JustinyAhin/threadcast
brew install threadcast

The repo is private, so Homebrew can't download the release assets — they require authentication.

You have a few options:

1. Make the repo public — simplest fix, Homebrew will just work
2. Host binaries elsewhere (S3, Cloudflare R2, etc.) — keep repo private but serve assets from a public URL
3. Set HOMEBREW_GITHUB_API_TOKEN — works for you locally, but anyone else installing would need to do the same

Which approach works for you?

Here's what you need to set up:

R2 Setup

1. Cloudflare Dashboard → R2 → Create bucket (e.g. threadcast-releases)
2. Settings → Public access → enable either the r2.dev subdomain or a custom domain
3. R2 → Manage R2 API Tokens → Create API token with Object Read & Write on that bucket
4. Copy the Access Key ID, Secret Access Key, and note your account ID

GitHub Secrets

Add these to JustinyAhin/threadcast → Settings → Secrets:

• R2_ACCESS_KEY_ID
• R2_SECRET_ACCESS_KEY
• R2_ENDPOINT — https://<account-id>.r2.cloudflarestorage.com
• R2_PUBLIC_URL — your bucket's public URL (e.g. https://pub-xxx.r2.dev or your custom domain)

Workflow Changes

Here's what changed:

1. release job — added an "Upload to R2" step that copies the .tar.gz files to s3://threadcast-releases/cli/v{version}/
2. update-homebrew job — downloads checksums from R2 instead of GitHub releases, and the formula URLs now point to R2_PUBLIC_URL instead of GitHub

Secrets you need to add

The R2 bucket name is hardcoded as threadcast-releases — adjust if you name it differently.

The formula in homebrew-threadcast still has the old GitHub URLs — the workflow changes haven't been released yet.

To get it working you need to:

1. Create the R2 bucket + secrets (as described above)
2. Push the workflow changes
3. Run the release workflow again

Or if you want to test it right now before re-running the full release, you can manually upload the existing tarballs and update the formula:

# Download the tarballs from the existing GitHub release
gh release download cli-v0.0.1 --pattern "*.tar.gz" --dir /tmp/tc-release

# Upload to R2 (replace with your actual values)
for f in /tmp/tc-release/threadcast-*.tar.gz; do
  aws s3 cp "$f" "s3://threadcast-releases/cli/v0.0.1/$(basename "$f")" \
    --endpoint-url "https://<account-id>.r2.cloudflarestorage.com"
done

Then update the formula in homebrew-threadcast to point to your R2 public URL instead of the GitHub release URL.

Try installing again:

brew untap justinyahin/threadcast && brew tap justinyahin/threadcast && brew install threadcast

Auth is stored at ~/.threadcast/config.json. Both the locally-built binary and the Homebrew-installed one read from the same path, so your previous login persisted.

That's actually standard behavior for CLIs — gh, docker, aws all store config in ~/.{name}/. The Homebrew-installed binary is the same program, just installed to a different path.

Were you expecting it to require a fresh login, or is there a specific concern? Happy to change the behavior if needed.

Ah yeah, good point. Simplest fix — add an env var override for the config dir so you can point dev to a separate location.

Now when developing locally you can run with:

THREADCAST_CONFIG_DIR=~/.threadcast-dev bun run packages/cli/src/index.tsx

Production (Homebrew) stays on ~/.threadcast, dev uses ~/.threadcast-dev. No overlap.

Yeah, set it in the dev script so you don't have to remember:

Now bun run dev (or bun dev:cli from the root) automatically uses ~/.threadcast-dev.

Done. Both bun cli (root) and bun dev (packages/cli) now use ~/.threadcast-dev.

API_BASE_URL is hardcoded to http://localhost:5173. That gets baked into the compiled binary too. Is there a production URL this should point to? It should probably read from an env var so dev hits localhost and the released binary hits prod.

Same hardcoded ~/.threadcast path. Let me check if there are other files with the same issue.

Three places, only auth/config.ts respects the env var. Let me extract a shared helper and fix all of them.

Now export getConfigDir from auth/config.ts and update the references:

Also need to update the mkdir call in shared-sessions.ts since it was using the removed CONFIG_DIR:

Now all three files (auth/config.ts, shared-sessions.ts, session-index.ts) respect THREADCAST_CONFIG_DIR. Dev data stays in ~/.threadcast-dev, prod stays in ~/.threadcast.

Now add the env var to the dev scripts:

Now:

• Prod binary: no env vars set → defaults to https://threadcast.dev
• Dev (bun dev / bun cli): → http://localhost:5173

brew upgrade threadcast

Or if the version number hasn't changed (still 0.0.1), Homebrew won't see it as an upgrade. You'd need to:

brew reinstall threadcast

When you release a new version (e.g. 0.0.2), just:

brew upgrade threadcast

The release workflow already handles bumping the version in the Homebrew formula — it writes the new version + checksums and pushes to homebrew-threadcast. So brew upgrade will pick it up automatically.

The current 0.0.1 release was built from the old code with localhost:5173 hardcoded. The API_BASE_URL fix hasn't been released yet — you need to push the changes and run a new release for the compiled binary to pick it up.

The OAuth callback URL isn't the issue — the CLI uses Device Flow (no callback needed).

The localhost:5173 URL you're seeing is the API_BASE_URL being used to construct the share link. Let me check if the new release actually picked up the change. Did the latest release workflow pass?

Release passed. Let me check if the API_BASE_URL change was included in the commit that was released.

The change is in the released commit. The issue might be that Bun's bundler inlined process.env.THREADCAST_API_URL as undefined at build time, making it always fall back to https://threadcast.dev. But you're seeing localhost:5173...

Did you brew reinstall threadcast after the latest release ran? The Homebrew formula still points to the same version 0.0.1, so reinstall might have served a cached copy.

Try:

brew untap justinyahin/threadcast && brew tap justinyahin/threadcast && brew install threadcast

brew uninstall threadcast && brew untap justinyahin/threadcast && brew tap justinyahin/threadcast && brew install threadcast

Checksum mismatch — you ran the release 3 times for 0.0.1, each uploading different binaries to R2 (from different code). The formula's checksums are from one run but the R2 files are from another.

Easiest fix: run the release workflow one more time so the checksums and files are in sync. Or better, bump to 0.0.2 to avoid this kind of collision.

Updated to 0.0.2. Push this, then trigger the release workflow with version 0.0.2.

Once it passes:

brew uninstall threadcast && brew untap justinyahin/threadcast && brew tap justinyahin/threadcast && brew install threadcast

Already uninstalled from earlier. Just run:

brew untap justinyahin/threadcast && brew tap justinyahin/threadcast && brew install threadcast

The API is returning a 500. Can you check the Cloudflare Worker logs? Either via:

bunx wrangler tail --name threadcast

Or in the Cloudflare dashboard → Workers → threadcast → Logs.

The most likely cause is the THREADS_BUCKET R2 binding not being configured in production. Let me check.

ReferenceError: process is not defined — Cloudflare Workers don't have process.env. The API_BASE_URL change in @threadcast/shared broke it because the shared package is also imported by the web app.

Since the web app doesn't use API_BASE_URL (only the CLI does), the fix is to move the env var check out of shared and into the CLI.

Now override it in the CLI's api-client instead:

Let me also check if API_BASE_URL is used elsewhere in the CLI.

Only used in api-client.ts. Push this and redeploy the web app — the process is not defined error will be fixed. The CLI will still respect THREADCAST_API_URL from the dev scripts.