Skip to main content
This page offers troubleshooting guidance for Bolt integrations. The tips here assume you already have some familiarity with the underlying technologies. If you’re new to one of the tools covered on this page, start there first: GitHub, Supabase, Expo, or Google SSO. Those pages include introductory information to help you get set up before you start troubleshooting.
Running into an error while publishing or deploying your project? See Publish issues.

​
GitHub sync issues

In your own projects, Bolt syncs to GitHub every time you make a change. If collaborators edit your project, their changes sync the next time you open the project. If your changes don’t sync to GitHub as expected, reauthorizing the GitHub app can help refresh the connection and get your sync working again. To reauthorize your GitHub connection:
  1. On the Bolt homepage, below the chatbox, click the GitHub option.
  2. In the Import a repository dialog, click Configure the GitHub App. The Install Bolt.new (by StackBlitz) page opens.
  3. Select your GitHub account. The Install & Authorize Bolt.new (by StackBlitz) page opens.
  4. Click Install & Authorize, then follow the on-screen instructions to enter your credentials. When GitHub finishes verifying your credentials, you’re returned to Bolt, and your connection is refreshed.

​
GitHub authentication issues

Sometimes, GitHub authentication conflicts can occur if you’ve connected the same GitHub account to more than one Bolt account. This usually happens when:
  • You originally signed up for Bolt using your GitHub account.
  • Later, you created a new Bolt account and tried to connect that same GitHub account through the GitHub integration.
When you use GitHub to sign in to Bolt, Bolt uses that same GitHub connection for the GitHub integration. You can’t separate the two, so if you want to use the same GitHub account with a new Bolt account, you’ll need to adjust your setup first. Follow the steps below to resolve this issue.
1

Create a new login method for your original Bolt account

  1. In your first Bolt account (the one you signed up for using GitHub), reset your password using the email address associated with your GitHub account.
    This adds an email and password login option to that account.
  2. Log out once the reset is complete.
2

Remove GitHub authentication from the old account

  1. Log back in to the original account using your new email and password credentials.
  2. Click Settings in the left menu.
  3. Click the Credentials tab.
  4. Under GitHub, click Delete to remove GitHub as an authentication method.
3

Connect the GitHub integration to your new account

  1. Log in to your new Bolt account (the one you want to use going forward).
  2. Go through the usual steps to connect the GitHub integration.

​
Expo or EAS CLI login fails in the Bolt terminal

If you experience this problem, you might first see this message in the Expo Go app on your phone, rather than an error from Bolt itself:
Expo Go expects the terminal running your Bolt preview to be signed in to Expo with the same account as your phone. If you’ve signed in to Expo Go on your phone but haven’t signed in to Expo from Bolt’s terminal, Expo Go blocks the preview and shows this message. This message on its own isn’t an error. The error occurs if you run a command to log in to Expo and the login fails (as covered in the following sections). You might also reach this point directly from Bolt, without seeing the Expo Go message first, most often right after Bolt asks you to upgrade an Expo project to a newer SDK, or any other time Expo asks you to log in from Bolt’s terminal. If you’re told to log in to Expo, run the command in Bolt’s own terminal, not a terminal on your own computer. To run the command in Bolt’s terminal:
  1. In your Bolt project, click the code icon (</>) in the top center of your screen to switch to Code view.
  2. In the bottom panel, click Terminal.
  3. Type npx expo login or npx eas-cli login, then press ENTER.
Depending on which command you use, you’ll see one of the following:
  • expo login fails with Error: socket hang up.
  • eas-cli login opens a browser screen asking you to allow eas-cli to access your Expo account. After you approve it, the browser shows This site can't be reached, localhost refused to connect.
Both commands try to send you back to a browser on your own computer to finish logging in. Since Bolt’s terminal doesn’t run on your computer, that never happens, and the login gets stuck. To fix this, create a personal access token on Expo’s site and add it to your Bolt project, instead of logging in through the browser each time.
1

Create a personal access token

  1. Go to expo.dev/settings/access-tokens and log in with your Expo account.
  2. Create a new personal access token and copy it.
2

Add the token to your Bolt project

Add the token to your project as EXPO_TOKEN, either in your project’s .env file, or as a secret:
  1. Click the database icon in the top center of your screen.
  2. Click Secrets.
  3. In Name, enter EXPO_TOKEN. In Value, paste your token.
  4. Click Create secret.
3

Run your command again

Run the npx expo login or npx eas-cli login command again. With EXPO_TOKEN set, it completes automatically, and you won’t need to log in through the browser again for this project.
If you added EXPO_TOKEN and still see a login error, confirm you copied the full token and that the secret name is exactly EXPO_TOKEN. These steps fix your login access only for the project where you added the secret. If other Expo projects run into this issue, you’ll need to add the token again for each one.
If you’re following Build and publish with Expo Application Services and running eas login on your own computer after downloading your code, that’s a different way of logging in. You shouldn’t see this issue there.

​
Supabase row-level security rules aren’t working

If your Supabase row-level security (RLS) rules aren’t behaving as expected (such as returning no data, exposing too much data, or causing authorization errors), it’s often due to a misconfigured policy or a mismatch between your schema and the rule conditions. You can resolve this by resetting your RLS configuration and reapplying the correct rule through Bolt. To do so, follow these steps:
  1. In the chatbox, prompt Bolt to remove all existing row-level security rules from the affected Supabase table. This clears out any incorrect or conflicting policies.
  2. Once the rules are removed, prompt Bolt to add back the relevant row-level security rule. Be specific about the intended behavior (for example, “only allow users to view rows where user_id matches their authenticated ID”).
  3. After the new rule is applied, test your queries or endpoints again to confirm the policy is now enforced correctly.
If the issue persists, check that the table’s RLS feature is enabled in Supabase.

​
Server functions

Server functions connect your project to external services, like OpenAI, Notion, Stripe, or GitHub, and to your database. Each type of connection can run into its own issues:
  • CORS errors happen when a web browser tries to call a server function from a domain your CORS configuration doesn’t allow.
  • Authorization header or JWT issues happen when external services like Stripe or GitHub send webhook requests without a JSON Web Token (JWT). When this happens, ask Bolt to turn off JWT verification for that function and add another way to validate the request.
  • Missing secrets happen when a server function tries to connect to an external API, like OpenAI, without the credential it needs.

​
CORS (cross-origin resource sharing) errors

If your server function isn’t working, it may be due to a CORS error. To check this:
  1. Open Chrome DevTools: press Command + Option + J on Mac, Control + Shift + J on Windows or Linux.
  2. Check the Network tab. Look for errors related to CORS.
  3. Next, check whether the CORS headers in your server function’s file are set correctly. Here are the CORS headers for a chatbot built with Bolt using OpenAI:
You can use Plan mode to ask Bolt if CORS headers exist and are set correctly in your application.

​
Missing secrets

If your project expects a secret you haven’t created yet, you’ll see the following message:
Server functions use secrets to let your project securely connect to outside services, like OpenAI or Stripe. A secret stores the credentials the service needs to grant your project access. For example, to connect to OpenAI, you need to add your OpenAI API key as a secret.
These steps work whether you have a Bolt database or have connected or claimed a Supabase database to use with Bolt.If you do manage your database in Supabase, you can also add secrets in the Supabase dashboard under Edge Functions > Secrets. Making the change in either place updates the same secrets.
1

Open the Secrets settings

  1. In your Bolt project, click the database icon at the top center of the screen.
  2. Click Secrets.
2

Add the secret

  1. In Name, enter the name that your server function uses for the secret.
  2. In Value, enter the secret key or password.
  3. Click Create secret.
For example, to connect to OpenAI, enter OPENAI_API_KEY in Name, then paste your OpenAI API key in Value.
3

Continue your work

The secret is available to your server function right away. You don’t need to redeploy it. If Bolt pauses and asks you to add the secret, tell Bolt you’ve added it so it can continue or test your project.
In shared projects, only the project Owner or a Co-owner can view or add secrets.
For more information about viewing, creating, and deleting secrets, see Database: Secrets settings.

​
Webhooks: authorization headers and JWT

When a third-party service (such as GitHub, Slack, or Stripe) triggers a webhook in your project, the request comes from outside your app’s authentication system, so it won’t include a valid JSON Web Token (JWT). By default, server functions expect authenticated requests. If JWT verification is still turned on, your webhook calls from external services will fail with an authorization error. To fix this:
  1. In the chatbox, ask Bolt to turn off JWT verification for the server function that receives the webhook.
This allows the function to accept incoming requests from third-party services that don’t use your app’s authentication.
  1. Add your own checks inside the server function to confirm each request is legitimate. For example:
    • Validate a secret or signature header provided by the third-party service.
    • Confirm the request source matches the expected domain or IP range.
Refer to GitHub’s validating webhook deliveries for example steps. If your app name or logo isn’t appearing on the Google sign-in screen, the issue is usually in your Google Cloud Console branding configuration rather than in Bolt. To check, sign in to Google Cloud Console and go to Google Auth Platform > Branding. The most common causes are:
  • Your branding hasn’t been verified. Google requires verification before your app name and logo appear on the consent screen. If you haven’t submitted for verification yet, click Verify branding.
  • Your branding hasn’t been published. Verification and publishing are separate steps. After verification is complete, click Publish branding to make your changes live.
  • Your Google OAuth app is in Testing mode. Even with verified and published branding, your app name and logo won’t appear if your publishing status is set to Testing. To fix this, go to Google Auth Platform > Audience and publish your app.
To learn more, see Manage OAuth App Branding in Google’s support documentation.