Operate remote code execution with Polyaxon
Operate remote code execution through Polyaxon with explicit session ownership, command receipts, artifact collection, and safe retry decisions.
Remote code execution lets an agent application keep its reasoning process separate from the environment running its commands. That separation is useful only if the application can tell who owns the environment, what completed, and what remains after a failure.
Polyaxon provides authenticated sandbox access to a running service. Build a small execution controller around that interface rather than treating a remote terminal as a complete job-management system.
Assign and verify the execution target
Maintain a trusted mapping from application session to Polyaxon project and run UUID. Resolve that mapping after authenticating the caller. Do not accept an arbitrary run identifier from a model and assume it belongs to the current user.
Create the service from a reviewed component with the required image, resources, workspace volume, and lifetime. The quick start shows how to wait for a running service and check sandbox health.
A service may remain running across several tool calls. Its container configuration and attached credentials apply to all commands inside it, so keep the environment no more privileged than the session requires.
Collect a complete command receipt
A useful receipt includes an application request ID, execution run UUID, command profile, start time, duration, exit status, timeout state, and output truncation flags.
Use the process API for structured execution results. Stream output when the user needs progress, but preserve a final outcome separately from the stream.
For commands that produce report files, return a manifest of expected outputs. Retrieve only approved paths with the filesystem API and enforce size limits before storing or displaying their content.
Avoid including secrets or full sensitive inputs in receipts. The receipt should make the execution explainable without becoming another uncontrolled copy of the dataset.
Reconcile uncertain outcomes
Network failure creates an important third state between success and failure: unknown. The process may have completed while the controller lost its response.
| Operation | Recovery approach |
|---|---|
| Pure calculation on fixed inputs | Reexecute if the resource budget allows |
| File generation in the assigned workspace | Inspect the expected receipt and output revision |
| External database update | Use an application idempotency key or transaction record |
| Deployment or publication | Require explicit reconciliation before retrying |
These decisions belong in application code. An LLM should not infer whether a write is safe to repeat from a timeout message.
When background execution is used, preserve its handle and define how the controller reconnects or determines completion. A timeout while waiting for a handle is not equivalent to stopping the process.
Separate evidence collection from cleanup
Download and validate useful outputs before ending the session. A trusted job can persist approved evidence through Polyaxon artifacts.
Then stop the service according to the session policy. Use termination limits as a backstop for forgotten runs, not as the only cleanup mechanism.
Stopping compute does not revoke external credentials or erase durable volumes. Include those systems in the session teardown procedure when they were provisioned for the task.
Remote execution becomes dependable when its lifecycle is explicit: authorize a target, execute a bounded request, reconcile the outcome, preserve evidence, and release the environment.