Custom Action environment variable edits don't take effect until a manifest redeploy — real risk of silent stale config

[kenlyle]

Summary: Editing a custom Action’s environment variable (e.g. via the Action Editor’s Save/“Update and Close”) persists the
new value in storage, but the action’s live execution runtime continues using the old value until something forces a fresh
deploy. There’s no UI indication that this is happening — a saved change looks successful and simply doesn’t apply.

Actions affected: propose_personas and confirm_personas (custom Python actions, both using JOBSGLIDER_BASE_URL and
PICKAXE_API_SECRET env vars).

Reproduction, with exact evidence:

1. JOBSGLIDER_BASE_URL was originally misconfigured (pointed at the wrong host). Corrected via the Action Editor.
2. Confirmed via my own server’s request logs that calls were still arriving at the old wrong host — every call returned an
   identical, byte-for-byte 404 response (same HTML page), timestamped well after the save.
3. Re-saved the value three separate times across ~1 hour, using both “Save Action” and “Update and Close” — identical stale
   result every time, confirmed via server logs each time (not just UI appearance).
4. Asked Wingman to introspect the actual stored value directly (bypassing the UI). It confirmed the value was correctly
   updated — cited the masked-value suffix changing as proof of a real write.
5. Despite the confirmed-correct stored value, the action still executed against the old host — another identical stale 404 at
   2026-09-25T16:32:25Z.
6. Wingman’s diagnosis: most serverless Python runtimes read os.environ once at container warm-start, not per-invocation — a
   warm instance can hold a stale value indefinitely regardless of how many times the stored config is updated.
7. Wingman performed a no-op manifest PUT (same code, no logic changes) to force a fresh deploy/cold start for both actions,
   redeployed at 2026-09-25T16:46:32Z / 16:46:33Z.
8. Immediately after, the action executed correctly against the new value — real success at 16:46:40Z, four minutes after the
   forced redeploy, roughly an hour after the underlying config was first corrected.

Impact: Any environment variable change to a custom Action is unreliable without a manual, undocumented workaround (a no-op
manifest redeploy). A builder has no way to know their save didn’t actually apply — the UI gives no warning, and the only
symptom is the action continuing to fail or misbehave exactly as before the “fix.”

Requested fix: Either (a) read environment variables per-invocation rather than caching them at container start, or (b)
automatically trigger a redeploy/cache invalidation whenever a variable is saved, so a save is never silently a no-op. At
minimum, (c) surface in the UI when a variable change requires a manual redeploy to take effect.

[kyle_support]

Hi @kenlyle,

Thanks for sending this bug report in. You are correct that changing your environment variable in the action editor saves it to the custom action, but actions already connected to an agent will keep their existing values. If you would like to update your environment variables for an already connected action, the expected flow is to click “Edit Connection” on the action’s settings in the builder and update the environment variables there. Let us know if you have any questions regarding custom actions or if you come across any other issues!

[kenlyle]

Thanks, Kyle. That explains what we saw, and we withdraw the container-caching theory from the original post.

Edit Connection works as you describe. I confirmed it in the UI with a probe action that echoes its env var: after Edit Connection, the next run used the new value with no redeploy.

One thing doesn’t match your description. You said the Action Editor “saves it to the custom action.” I set a value there, then created a brand-new Pickaxe and added the same action. The Probe Value field came up blank, and Save failed with “Variable Probe Value is required.” So the editor value is neither applied to connected actions nor offered as a default for
new ones, and the editor still says it saved. Your MCP server behaves the same way: action_connect without a value returns
invalid_variables, and nothing in the MCP can read or write the editor’s value (the manifest export lists only the variable definition).

What does that field do? If nothing, hiding it or labeling it would prevent others hitting this. We lost an hour to it.

[kyle_support]

Hi @kenlyle,

You are absolutely correct. Setting that field in the action editor does save the value, but does not set it as the default when you connect the action to an agent. For user created actions, you will have to set your own environment variable value every time you connect the action. Hopefully this cleared up all confusion but if you have anymore questions, please drop them in this thread!