ndirons

OK, I appreciate the explanation. Though as I said above, to document environment variable as "global" seems to elide context, at best.

I have a script filter which depends on cached JSON input, because it takes a couple of seconds to generate new data, and the results change infrequently. I thought I'd get the best of both worlds by generating the data if the cache is not found, or reading the cache if it's present, while also firing off a task to refresh in the background for use the next time the workflow runs. However, if the cache isn't found and I have to generate it before I can show the script filter, then I don't want to regenerate it again almost immediately. I handled this with an environment variable, and I modify its value to tell the delayed action whether it should rebuild the cache or just exit. Surprisingly to me, the delayed action never sees a change in the environment variable's state, even when it's executing seconds after the value changed. Testing suggests that a delayed action will always see env vars as they existed at the moment the delay was triggered, not when the action runs. Is this expected behavior? If so, the documentation of environment variables as "global" could use some nuance. I'm on Alfred 5.1.3 (2175), and the behavior is consistent on 14.0 and 13.5.2. Here's a sample workflow: https://www.dropbox.com/scl/fi/vzk8u8vp45a78jhryzlk0/Env-Var-Delay-Sample.alfredworkflow?rlkey=pa0sxraiezoks4anj6c92tupq&dl=0 Thanks for your time.

Hello, I just noticed that since updating to 1Password 4, which changed its app name to "1Password 4.app", Alfred has been capturing its clipboard data. 1Password 3 was blacklisted by default to prevent this from happening, and I'm guessing that the failure to blacklist the updated version is an oversight. Thanks for your time.