u/bjl218

I've been having some problems with my email recently. I'm not receiving certain messages and certain messages I've sent or not being received by others. I've received no bounce messages for emails I've sent. Users who have sent email to me have not reported any bounce messages. I sent a test message to Unspam which reported that the sending IP address is currently blacklisted by SpamCop. The IP address is 74.125.224.51 which is a Google IP address.

I suspect this is the cause of the delivery problems although none of my friends who use Gmail seem to have noticed any problem.

Additional information:

I have a vanity email domain hosted at SquareSpace with email forwarding to my Gmail account. Because of a different issue some time ago, I set the From address of all emails to my Gmail address and the Reply-To to my vanity address. Unspam didn't report this as a problem.

This has been going on for more than a week and so far, that IP address has not been removed from SpamCop's blacklist. Since I don't own that email address, I can't ask to have it removed.

Any other suggestions to address this problem?

A number of recipients have not been receiving email from me. I'm sending from the Web mail interface and the messages do show up in my Sent folder. I typically use my vanity email address which is hosted at Squarespace. As a test, I tried sending emails to my work email using my gmail.com address and my vanity address. Neither has arrived and its been a few hours. The last time this happened, it was squarespace's fault. But that was only when I sent using my vanity address. Any bounce messages might not happen for 48 hours. Any way to debug this before then?

Scheduled to fly CDG to BOS tomorrow 7/22 in mint. Incoming equipment looks like it’s leaving JFK at 7ish this evening. Wondering if I should try to rebook CDG to BOS for the following day (7/23) or wait it out.

Thoughts?

We use multiple schemas in our Supabase. It would help simplify my team's workflow if we didn't have to go into the Supabase dashboard to expose each schema after pushing the associated migration. It would also be great if this could be implemented for local development as well (i.e., not having to edit the config.toml file)

This is minor, but would help simplify my team's workflow:

For shared variables, add an "automatically inherit" setting so that all projects for that team inherit those shared variables without the linking step.

After a long Claude Code (Desktop) session, I noticed that the context window indicator (the little circle) was full and red. It said that I had used 260k of 200k! But it never compacted the context. I maintain a state memo file, so I just asked it to update the state memo and then I started a new session. Anyone else run into this?

Summary: We are using a single shared Supabase DB to support multiple cooperating applications. Each application will have its own named schema.

Following on from this post. I realize there are a number of issues with having multiple applications share a single DB, but we've decided to go this route, so I'd prefer to skip the debate about whether this is advisable or not.

I have some questions for those of you who may have done this:

1. How do you handle schema migrations? Do you just use the standard Supabase migration tools and let migrations for all applications/schemas exist in the one migrations table? The goal here would be to allow application developers to create schema migrations in their own named schemas and apply them to the shared DB. I'm debating between using the standard Supabase migration mechanism or using a different tool such a dbmate which would keep the schema migration table for a given schema in that schema and avoid any clashes between schema migrations coming from different apps. Although, I'm not certain that the schema clash issue is a significant concern since schema migrations are named and timestamped.
2. How do you handle cross-schema joins? Since the Supabase API does not support this, I was thinking of creating my own simple Data Access Layer (DAL) probably using postgres.js under the covers. The DAL would do the correct RLS init/setup before executing each query to ensure that RLS still works. Since most if not all of the queries will be generated using AI, I'm not that worried about providing a developer-friendly, ORM-like API at this point.

We have a number of apps that share the same data and so we're considering keeping all data in a single Supabase DB. Data that is specific to a given app will be kept in separate schemas. I'm wondering if anyone else is doing this. If so, how do you manage schema migrations? Do all developers have to create schema migrations in a specific project that is linked to Supabase? Or are the schema migrations created in each application project and somehow coordinated?

Edit: One option I read about just now is to use Supabase schema migrations for the "main" project and then each app project uses a different schema migration tool (like Drizzle) for their own schemas. This keeps the schema migration mechanism (including any schema migration tables) isolated in the individual schemas

I've created a Github repo that will contain a number of skills that my organization will be using. I've instructed my team on how to use the claude plugin marketplace add command to add the marketplace and then use claude plugin install to install the skill. This works fine. However, I noticed the the marketplace add command pulls down the entire Github repo into ~/.claude/marketplace/<my_marketplace_name>. This is not a big problem other than the fact that the repo contains more than just the skills.

Claude's recommendation (which is pretty obvious when you think about it) was just to create a separate Github repo that contains only the skill(s). I could do this, but I really like the fact that this repo (a monorepo I suppose) contains other common packages that my team uses. Skills are just one type of common package.

Claude's other recommendation was to create a separate Github repo that contains only the .claude-plugin/marketplace.json file which would have a reference to the repo that contains the skill(s). So in the plugins array in the marketplace.json file, we'd have something like:

"plugins": [
  {
    "name": "my skill",
    "description": "my description",
    "source": {
      "source": "git-subdir",
      "url": "https://github.com/myorg/my_common_packages_repo.git",
      "path": "skills/my_skill"
    }
  }
]

I'm wondering what other folks are doing to manage private Claude marketplaces and plugins/skills

Edit: the path of least resistance seems to be to put the skills in their own Github repo. But I'd still like to know whether others have any additional advice.

I've run into a number cases in which code runs fine in my local Vercel development environment user vercel dev, but breaks when deployed. This mostly occurs in my back-end APIs which are implemented as Vercel functions. My AI tells me that this is because vercel dev uses esbuild to bundle the API routes and esbuild is a bit more 'forgiving' than the deployed Vercel environment. For example, even though I'm using ESM, esbuild is OK with imports that lack .js extensions.

So I've had to fix the errors in deployment one at a time as I hit them which is a bit annoying. What can I do in my local dev environment to ensure that what works locally, works when deployed?

I also asked Claude whether my use of Vite vs Next.js is contributing to this and here is its response. Do folks agree? Seems like the path of least resistance is just to switch to Next.js

With Next.js + Vercel:
Vercel built Next.js. The dev server (next dev) and the production build use the same pipeline for both frontend and API routes. What runs locally is very close to what runs in production — same module resolution, same runtime behavior. Vercel's vercel dev command is essentially unnecessary for Next.js projects because next dev already does it correctly.

With Vite + Vercel:
Vite owns the frontend dev server. When you run vercel dev, Vite handles the browser side while Vercel's u/vercel/node runtime handles the API routes using esbuild. The problem is that in this setup, esbuild bundles the API routes in a way that's more permissive than what production actually runs — it masks ESM extension issues and the Vite dev server bleeds browser globals into the API function environment.

So the Vite + Vercel combo creates a seam between two systems (Vite and vercel/node) that don't share the same assumptions, and vercel dev papers over that seam in ways that production doesn't.

If avoiding this class of problem were a priority, Next.js + Vercel would give you much tighter dev/prod parity for the serverless function side. But for a project that's already built on Vite, it's not worth switching — vercel build before pushing and the CLAUDE.md guidelines address the practical risks.

This doesn't seem to be handled in the UI. I found some references to this which suggested a delete the project folder under ~/.claude/projects. I did that, but the project still shows up in the desktop app. I assume it must be cached somewhere that I can hopefully delete, but where? AIs including Claude itself give me incorrect information.

I have 2 Vercel + Supabase projects. Let's call them Project A and B. Project A already exists and will be used as the IdM. That is, Project B will authenticate against Project A*. I'm currently designing Project B. Project B will also need to access certain tables in Project A. Exact tables are TBD. AFAIK, the 2 primary ways to accomplish this are:

1. Project B uses the JWT obtained after authenticating with Project A to access Project A's tables via the Supabase API. Or use the service role (all business logic is in Vercel functions).
2. Use PostgresQL Foreign Data Wrappers (FDW). This seems conceptually straightforward, but the devil is in whatever details I'm not familiar with. AI tells me that this is not too difficult to configure.

There are, of course, other options like syncing the required Project A tables to Project B, but aside from the latency issues, that doesn't seem very robust.

I'd be interested in any other experiences and/or recommendations on best practices here.

*I'd actually like to use a 3rd-party IdM like Auth0 or Keycloak, but I haven't gotten that past the team yet.

I'm creating a skill which will be hosted in our private github repo. I've successfully configured that repo and installed my in-progress skill from that repo in Claude Code. Now I'm going to do iterative development on that skill and I don't want to have to push it to the Github repo and re-install it each time. I want to be able to modify the skill locally and have that change immediately available to Claude. I've learned about the --plugin-dir command-line argument to Claude. However, that apparently doesn't work in the Claude desktop app which where I'd prefer to test it.

I've noticed that when the skill is installed at user scope, a ~/.claude/plugins/installed_plugins.json file is created that includes the install path of the plugin. The install path includes the short commit SHA and there are additional properties including timestamps and the full commit SHA. I thought about creating a symlink from the installPath in the installed_plugins.json file to my local project. OR just continuing my development in Claude terminal rather than the Claude desktop app.

I think the correct approach might be to remove the marketplace-based install and do I manual install by creating a symlink in ~/.claude/skills:

cd ~/.claude/skills
ln -s <local_repo_root>/skills/<skill-name>

and this should work in both the Claude terminal and desktop apps. I've asked Claude about this, but its response was unclear.

How are other folks managing their local skill development environments?

All,

I am relatively new to Supabase although I have lots of experience deploying to Cloud environments where I had to roll my own environment/branching workflow. Typically, I'd define 3 full standalone environments/branches: dev, staging, production each with its own client and server stacks and database instance. Developers typically work directly in the dev branch or there own branches and then merges are done manually when its time to promote something to staging or production.

In my current gig, we are using Vercel and Supabase and so I'm wondering what branching/environment strategies folks are using. I know that both Vercel and Supabase support branches. And Supabase has some magic that will automatically instantiate an ephemeral DB instance when it detects a new PR and automatically apply schema migrations when the PR is merged into main (or whatever the production branch is).

But I can also see that with a little less magic and bit more work, Vercel/Supabase can support the "persistent" multi-environment branching to which I'm more accustomed as described above.

So I'm wondering what folks are doing in this area. Magic always worries me, but I'm willing to learn.

I had my first appointment with my provider since being on Medicare. My PCP is part of Beth Israel Lahey Health and is located in one of the hospital buildings. I received the eMSN for this visit and the claim included a note that said:

>B Payment was reduced because this service was performed in a hospital outpatient setting rather than a provider's office.

I haven't met my deductible yet and so I'm responsible for the (relatively small) amount. So, would I have been charged less if I had seen a provider that was not within the hospital? Or is this saying that they reduced the allowed amount, but the cost to me is still the same?

Edit: Just a note that I did chat with Medicare about this online, but their responses were confusing.