internal/runtime/builtin/docker/executor.go (1)

471-484: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Use step-aware evaluation for container.env values too.

ct.Env still flows through evalEnvSequentially, and Line 521 there still uses runtime.EvalString(...). That leaves backtick substitution enabled for step-owned container env values, so inputs like FOO=\uname`can still execute even though the other container fields were moved toEvalStepString`.

Suggested fix

 func evalEnvSequentially(ctx context.Context, envs []string) ([]string, error) {
 	if len(envs) == 0 {
 		return envs, nil
 	}
 	resolved := make(map[string]string, len(envs))
 	result := make([]string, 0, len(envs))
 	for _, entry := range envs {
 		key, rawVal, found := strings.Cut(entry, "=")
 		if !found {
 			result = append(result, entry)
 			continue
 		}
-		val, err := runtime.EvalString(ctx, rawVal, eval.WithVariables(resolved))
+		val, err := runtime.EvalStepString(ctx, rawVal, eval.WithVariables(resolved))
 		if err != nil {
 			return nil, fmt.Errorf("env %s: %w", key, err)
 		}
 		resolved[key] = val
 		result = append(result, key+"="+val)
 	}
 	return result, nil
 }

Also applies to: 490-498

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@internal/runtime/builtin/docker/executor.go` around lines 471 - 484, ct.Env
is still evaluated via evalEnvSequentially which uses runtime.EvalString and
thus allows backtick substitution for step-owned env values; change the env
evaluation to the step-aware evaluator used for other container fields (i.e.,
use EvalStepString instead of runtime.EvalString). Update evalEnvSequentially
(or create a new evalEnvStepSequentially) to call runtime.EvalStepString for
each env value so container environment variables are evaluated with step
scope/escaping consistent with ct.Volumes, ct.Ports, ct.Command and ct.Shell.