[Bug Report] Create-time envs are not fully propagated to sandbox runtime execution

[zyl1121]

Summary

Create-time envs passed through Sandbox.create(envs=...) are not fully propagated to sandbox runtime execution.

On current origin/master, both commands.run and run_code miss those create-time envs. After applying the related CubeAPI-side fix, commands.run works, but run_code still does not.

This issue is a follow-up to #427. That earlier issue captured the broader propagation gap, and maintainer feedback there clarified that generic environment refresh at sandbox startup is not currently supported.

Environment

• CubeSandbox version / commit: current origin/master
• Host OS and kernel version: Rocky Linux 9.6, 5.14.0-570.17.1.el9_6.x86_64
• KVM info (modinfo kvm): host supports KVM; the issue is in the control/runtime integration path rather than KVM itself
• Deployment mode: cluster
• Relevant component: CubeAPI / sandbox runtime image / bundled lightweight code interpreter

Steps to Reproduce

1. Create a sandbox through the E2B SDK with create-time envs on current origin/master:

from e2b_code_interpreter import Sandbox

with Sandbox.create(
    template="tpl-xxxx",
    envs={"CUBE_TEST_CREATE": "from-e2b-create"},
) as sandbox:
    print("commands.run:")
    print(sandbox.commands.run("echo $CUBE_TEST_CREATE").stdout)

    print("run_code:")
    result = sandbox.run_code(
        "import os; print(os.environ.get('CUBE_TEST_CREATE', '<NOT SET>'))"
    )
    print(result.logs.stdout)

2. Observe the behavior of commands.run and run_code.

Actual Behavior

On current origin/master:

commands.run:


run_code:
['<NOT SET>\n']

Both execution paths fail to see the create-time env var.

Related PR / Partial Verification

A separate CubeAPI-side PR is prepared for the CubeAPI -> envd propagation layer.

Related CubeAPI-side PR: #566

With that PR applied, the same script produces:

commands.run:
from-e2b-create

run_code:
['<NOT SET>\n']

So the related PR fixes the CubeAPI -> envd propagation layer for envd-backed command execution, such as commands.run.

The remaining gap is that run_code still does not inherit sandbox-level envs, because the bundled lightweight code interpreter in the sandbox image does not currently read envd /envs.

Additional Context

Verified split of the problem

The issue currently breaks down into two layers:

1. CubeAPI create-path propagation
2. runtime/image-side run_code propagation

The related CubeAPI-side fix addresses the first layer by:

• accepting E2B SDK envs as an alias of envVars
• posting create-time envs to envd after sandbox creation succeeds

That is enough to restore commands.run.

This keeps the follow-up narrowly scoped relative to #427: it does not claim that every runtime path now supports startup-time env refresh.

Why run_code still fails

run_code does not go through the same envd-backed command path as commands.run.

The bundled lightweight code interpreter in the sandbox image does not currently read sandbox-level envs from envd /envs, so even after envd has the correct values, run_code still prints <NOT SET>.

Verified behavior with the related CubeAPI-side fix

Cluster validation confirmed:

• E2B SDK envs path works for commands.run
• CubeSandbox SDK native envVars path also works for commands.run
• per-call command env overrides still work
• after a per-call override, the next commands.run falls back to the sandbox-level env again
• pause / resume preserves the same commands.run env visibility in the current lifecycle model

So for the currently verified lifecycle:

• a single create-time envd /init call is sufficient for commands.run
• a separate resume-time re-init path does not appear necessary

Suggested follow-up direction

For the remaining run_code gap, the most direct follow-up appears to be updating the bundled lightweight code interpreter to read sandbox-level envs from envd /envs before applying per-call env overrides.

Preferred precedence:

sandbox-level envs from envd < per-call envs

Maintainer feedback requested

Would updating the bundled lightweight code interpreter to read envd /envs be the preferred follow-up direction for making run_code consistent with commands.run?

A separate CubeAPI-side fix is prepared for the first layer: propagating create-time envs into envd so that commands.run works correctly.

[cubesandboxbot]

This issue might be related to a previously reported issue. Please check:

• [Bug Report] Sandbox.create(envs=...) environment variables are silently dropped #427 — "Sandbox.create(envs=...) environment variables are silently dropped": This earlier report described the same Sandbox.create(envs=...) propagation gap. It was closed by a maintainer who noted that env refresh at sandbox startup is not currently supported and suggested a workaround. Issue [Bug Report] Create-time envs are not fully propagated to sandbox runtime execution #565 appears to be a follow-up that narrows the scope to the remaining run_code gap after a partial CubeAPI-side fix for commands.run.

Please consider linking these issues for continuity so the remaining run_code gap can be tracked in context.

[zyl1121]

This issue might be related to a previously reported issue. Please check:

• [Bug Report] Sandbox.create(envs=...) environment variables are silently dropped #427 — "Sandbox.create(envs=...) environment variables are silently dropped": This earlier report described the same Sandbox.create(envs=...) propagation gap. It was closed by a maintainer who noted that env refresh at sandbox startup is not currently supported and suggested a workaround. Issue [Bug Report] Create-time envs are not fully propagated to sandbox runtime execution #565 appears to be a follow-up that narrows the scope to the remaining run_code gap after a partial CubeAPI-side fix for commands.run.

Please consider linking these issues for continuity so the remaining run_code gap can be tracked in context.

Thanks for pointing to #427.

This issue is intended as a narrower follow-up rather than a duplicate report.

My current understanding is:

• in [Bug Report] Sandbox.create(envs=...) environment variables are silently dropped #427, maintainer feedback clarified that generic environment refresh at sandbox startup is not currently supported
• the related PR for this issue does not try to introduce that broader runtime contract
• it only restores the CubeAPI -> envd propagation path for envd-backed command execution, such as commands.run
• run_code still does not inherit sandbox-level envs on the current runtime image, which is why this issue remains focused on the remaining interpreter-side gap

So the intended split is:

1. PR fix(CubeAPI): propagate create-time env vars to envd-backed commands #566 fixes the verified CubeAPI -> envd propagation gap for envd-backed commands
2. this issue tracks the remaining run_code gap in the bundled lightweight code interpreter

If that separation sounds right, I can keep the PR scoped to the envd-backed command path only and leave the broader runtime-side behavior for follow-up discussion here.