Does the Cursor cloud VM strip or intercept outbound HTTP Basic Auth headers to external hosts?

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

We’re running cloud agents and hitting a 401 when Composer tries to download a package from a private registry (advancedtables.privato.pub) during the start step.

Steps to Reproduce

What we do:

In install.sh we run:

composer config --auth http-basic.advancedtables.privato.pub
“$FILAMENT_ADVANCED_TABLES_PLUGIN_EMAIL”
“$FILAMENT_ADVANCED_TABLES_PLUGIN_KEY”
composer install
Both FILAMENT_ADVANCED_TABLES_PLUGIN_EMAIL and FILAMENT_ADVANCED_TABLES_PLUGIN_KEY are set as Cursor Team Secrets and validated

The error (from the start step):

Downloading archilex/filament-filter-sets (v3.8.12)
The ‘https://advancedtables.privato.pub/composer/11/153/download’ URL required authentication (HTTP 401).
You must be using the interactive console to authenticate

Our question: Does the Cursor cloud VM strip or intercept outbound HTTP Basic Auth headers to external hosts? Or is there a reason the auth.json written during the install step would not be available during the start step (e.g. workspace snapshot does not preserve gitignored files)?

Any guidance on how to correctly pass Composer HTTP Basic credentials to a private registry in the cloud agent environment would be much appreciated.

Operating System

MacOS

Version Information

Cloud agents

For AI issues: which model did you use?

Sonnet 4.6

Does this stop you from using Cursor

Yes - Cursor is unusable

It’s unlikely that auth headers are being stripped, but we can quickly rule it out. The more likely cause is that PHP Composer’s file-based auth (auth.json) isn’t available when the download actually happens.

The cleanest fix is to bypass file-based auth entirely and use PHP Composer’s built-in COMPOSER_AUTH environment variable. Since Cursor Team Secrets are injected as env vars, Composer will read them automatically.

Option A (single secret, recommended): Create a new Cursor Team Secret:

  • Name: COMPOSER_AUTH

  • Value: {"http-basic": {"advancedtables.privato.pub": {"username": "your-email", "password": "your-key"}}}

Then remove the composer config --auth line from your script. Composer will use the env var for all auth automatically.

Option B (keep your two existing secrets): Add this to the top of your script before composer install:

export COMPOSER_AUTH="{\"http-basic\": {\"advancedtables.privato.pub\": {\"username\": \"$FILAMENT_ADVANCED_TABLES_PLUGIN_EMAIL\", \"password\": \"$FILAMENT_ADVANCED_TABLES_PLUGIN_KEY\"}}}"

If the COMPOSER_AUTH approach still results in a 401, that would tell us the issue is at the network/proxy layer rather than file persistence, and we’d investigate further on our end.

One clarifying question: is install.sh configured as the install command or the start command in your environment setup?