I’m developing an OSDK React application on Developer Tier. This command fails with getaddrinfo ENOTFOUND for our configured Foundry enrollment hostname:
npm ci --include=dev --no-audit --no-fund
On October 21, I reproduced hostname-resolution failure in both:
AI FDE’s repository-bound terminal, using Python’s system DNS resolver.
The interactive Foundry VS Code terminal, using Node’s dns.lookup.
Foundry itself remains accessible in my browser.
Environment versions:
AI FDE: Node v24.18.1, npm 11.19.1.
Interactive VS Code: Node v24.16.0, npm 11.13.0.
Registry and authentication configuration have not been changed. Dependency installation remains blocked, so tests, typecheck, lint, and build have not run.
Is the enrollment hostname expected to resolve from these environments? What is the supported way to diagnose and restore access to the existing Foundry artifact registry?
The workspace contains uncommitted and untracked work, so recovery steps need to preserve those files. If investigation requires private enrollment or workspace details, where should I provide them securely?
Read-only checks confirmed that Developer Console advertises the same hostname used by the project configuration and the original failed npm request. The project’s .npmrc remains unchanged from its committed template version.
In AI FDE’s repository-bound environment, npm’s proxy-selection logic selected direct connectivity, with no NO_PROXY bypass explanation. Whether direct connectivity is the intended platform route remains unconfirmed.
Current DNS status has not been retested. No installation retries or configuration changes were made.
I opened a private Sensitive Information Platform Support issue for enrollment-specific identifiers and internal routing details.
The last preservation check confirmed that the uncommitted files remained intact. A restore-tested archive is accessible from interactive VS Code, but a supported export outside the execution environment remains outstanding.
Could Palantir confirm the intended registry connectivity for these runtimes and the minimum additional read-only diagnostic needed?
The connection problem remains unresolved. Today’s DNS check in AI FDE’s repository-bound environment failed with:
socket.gaierror: [Errno -2] Name or service not known
This prevents restoring the project’s dependencies and running application tests or the build. Foundry itself still opens in my browser.
Registry and authentication settings have not been changed, and our uncommitted work has been preserved.
Please help identify the supported recovery step. Any recovery needs to preserve the existing workspace and its files. If you need private workspace details, please tell me how to provide them securely.
Accessing the url of your Foundry instance from a code repository is essentially equivalent to egressing to another website (which happen to be the same you are on). So you might need a REST source directed towards you own Foundry instance, and importing this in your code repository (to write your transforms/functions/etc. and for those to have access to this url when executing).
Also please make sure you upgrade your code repo/use the latest versions of node (see https://community.palantir.com/t/typescript-v2-functions-workspace-nodesetup-gets-403-downloading-node-24-16-0-but-ci-succeeds/7437/3)
I repeated the DNS check in the Foundry workspace today, and it still returns ENOTFOUND. The earlier npm ci attempt failed on the same hostname.
Could someone help confirm the correct endpoint and the supported steps to restore package access while preserving my uncommitted and untracked work? I can share the hostname and error details privately.
building on what VincentF said - inside the workspace npm isn’t supposed to reach your enrollment hostname at all. that hostname is what you use when developing locally with FOUNDRY_TOKEN. in a code repo / VS Code workspace, packages come through the repository’s own npm repos instead: the OSDK bundles (foundry-sdk-asset-bundle, osdk-templates-bundle), an npmjs mirror (external-npm-npmjs) and your OSDK artifacts repo. so if npm is resolving to the public hostname from inside the workspace, ENOTFOUND is kind of expected, it’s treated like egress.
read-only checks first:
npm config get registry
npm config ls -l | grep -i registry
this shows which .npmrc wins. if a project or user .npmrc points your @scope or the default registry at the enrollment hostname, that’s what’s breaking it
in the repo, Settings > Libraries should list the OSDK artifacts repo, if it isn’t there npm can’t find the package even through the proxy
to keep your work safe, commit everything (incl. untracked) to a new branch in the repo before trying anything. that’s the simplest supported way to get it out of the workspace, it’s just a branch, not master.
then:
4. upgrade the repo (top right > Upgrade, merge the PR) so the template and node versions are current, same fix as the thread Vincent linked
5. delete node_modules and package-lock.json, pause and resume the workspace, run npm ci again
if step 2 shows the hostname coming from the committed .npmrc, keep that file for local dev but don’t let it override the scope inside the workspace.
I’m trying to install the dependencies for an existing OSDK React application so I can build and test it. The installation command was:
npm ci --include=dev --no-audit --no-fund
It failed with:
getaddrinfo ENOTFOUND [Foundry hostname]
On November 2, I ran a separate DNS check in the Foundry workspace to investigate the failure. That check also returned ENOTFOUND for the same hostname.
Would a REST source apply to npm package installation in this situation, or is there another supported way to access the required package registry?
Also, how can I check the appropriate repository and Node versions and, if an upgrade is needed, perform it safely while preserving my uncommitted and untracked work?
I can share the actual hostname and additional error details privately if needed. Thank you.
our posts crossed, I put some read-only checks in my reply just above. on your two questions:
a REST source is for code that calls an external URL when it runs, it won’t help npm install. inside the workspace npm should go through the repo’s own npm repos (OSDK bundles, npmjs mirror, your OSDK artifacts repo), not your enrollment hostname. npm config ls -l will show if a .npmrc is pointing it at the hostname
for versions: if Upgrade shows in the top right menu of the repo, it’s not current. to keep your work, commit everything including untracked files to a new branch first, then run Upgrade, merge the PR into master, and only then pull master into your branch. your files never get touched that way
Hi Srini, thank you for your guidance. I completed the checks in my Foundry VS Code workspace:
The active default npm registry comes from the project’s .npmrc, and its hostname matches the one from the earlier ENOTFOUND error.
npm config get registry reports that the registry option is protected.
I tried a read-only lookup of the public react package using a temporary override to the public npm registry and a fresh temporary cache. It also returned ENOTFOUND. That test did not capture which hostname failed.
Settings → Libraries lists the OSDK bundles, the npm mirror, and a project-specific repository. There is also a warning that an external repository appears before an internal one.
What is the supported next step to test access to both the workspace’s package repositories and my generated OSDK without changing my uncommitted and untracked work?
Also, you mentioned deleting package-lock.json before running npm ci. Should the lockfile be kept or recreated first?
I can provide sensitive details privately if needed. Thank you.
thanks for running those. on the lockfile first, my mistake earlier: keep package-lock.json. npm ci needs it and won’t run without it (it clears node_modules by itself). don’t delete or recreate it
the public npm test failing with ENOTFOUND too is the useful bit. it means the workspace has no outside egress at all, which is normal, so the only way in is the registry your .npmrc points at. and that hostname isn’t resolving from inside the workspace either. since the registry setting is protected, that’s not something you can fix from your side
a read-only way to see exactly which host fails, without touching your project:
cd /tmp && npm view react version --loglevel http
cd && npm view version --loglevel http
the http log prints the full url npm tries, so you get the exact hostname for each one. neither command writes anything to your project
then I’d raise it with Palantir support and send the hostname, the two log lines and the Libraries warning about the external repo sitting before the internal one privately. registry DNS failing inside a dev tier workspace looks like a platform-side setup issue