[GH-ISSUE #5314] [feature]: read variables from OS environment #2032

New issue

Open

opened 2026-03-16 22:55:15 +03:00 by kerem · 1 comment

kerem commented

2026-03-16 22:55:15 +03:00

Owner

Originally created by @omniproc on GitHub (Aug 6, 2025).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5314

Is there an existing issue for this?

I have searched the existing issues

Summary

Make it possible to access operating system environment variables within Hoppscotch Desktop

Why should this be worked on?

Identical to the discussion open since 2015 in https://github.com/postmanlabs/postman-app-support/issues/1603

This could mean that it's possible to reference OS env vars from within the app env vars (e.g. for the value of a app env var use &&MY_OS_ENV_VAR&& or similar) or that something like process.env() to read OS env vars in a pre-request / post-request script is made available so they can be set as needed.

The request is not to automatically import all OS environment variables. They'd still have to be explicitly added by a user before they can be accessed. This makes sure there is no name conflict and OS environment variables are only exposed if explicitly configured by the user.

To prevent OS env var access by collection sharing I'd even go so far to only make the use of &&MY_OS_ENV_VAR&& possible within the value of a secret. This way it wouldn't be exported and a user would have to explicitly add it once the collection is imported.

Originally created by @omniproc on GitHub (Aug 6, 2025). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5314 ### Is there an existing issue for this? - [x] I have searched the existing issues ### Summary Make it possible to access operating system environment variables within Hoppscotch Desktop ### Why should this be worked on? Identical to the discussion open since 2015 in https://github.com/postmanlabs/postman-app-support/issues/1603 This could mean that it's possible to reference OS env vars from within the app env vars (e.g. for the value of a app env var use &&MY_OS_ENV_VAR&& or similar) _or_ that something like process.env() to read OS env vars in a pre-request / post-request script is made available so they can be set as needed. The request is _not_ to automatically import all OS environment variables. They'd still have to be explicitly added by a user before they can be accessed. This makes sure there is no name conflict and OS environment variables are only exposed if explicitly configured by the user. To prevent OS env var access by collection sharing I'd even go so far to only make the use of &&MY_OS_ENV_VAR&& possible within the value of a secret. This way it wouldn't be exported and a user would have to explicitly add it once the collection is imported.

kerem added the

feature

label

2026-03-16 22:55:15 +03:00

kerem commented

2026-03-16 22:55:26 +03:00

Author

Owner

@magratheaner commented on GitHub (Aug 27, 2025):

I strongly second this. I'm using aws cli to authenticate with AWS from the terminal daily using aws sso login and export the resulting secrets to env vars in the respective terminal. This is a common and fully supported use case of AWS as far as I'm informed.

If I could just use these env vars in hoppscotch without needing to implement another auth flow inside of the app, or worse, copying the values manually every day, that would be great, and certainly something that comparable solutions currently lack, as the OP mentioned.

Also I fully agree that if you actually enforce usage of env vars in exports somehow, this will make working with the app much safer for many teams, comparable to .env in .gitignore. But I think that should be done in another issue.

@magratheaner commented on GitHub (Aug 27, 2025): I strongly second this. I'm using aws cli to authenticate with AWS from the terminal daily using `aws sso login` and export the resulting secrets to env vars in the respective terminal. This is a common and fully supported use case of AWS as far as I'm informed. If I could just use these env vars in hoppscotch without needing to implement another auth flow inside of the app, or worse, copying the values manually every day, that would be great, and certainly something that comparable solutions currently lack, as the OP mentioned. Also I fully agree that if you actually enforce usage of env vars in exports somehow, this will make working with the app much safer for many teams, comparable to .env in .gitignore. But I think that should be done in another issue.

kerem referenced this issue

2026-03-17 01:12:12 +03:00

[PR #2032] [CLOSED] chore(deps): bump graphql from 15.8.0 to 16.2.0 #3603