Conductor runs coding agents against tracker content and repository workspaces. That is a powerful automation boundary and must be treated as security-sensitive.

The implementation uses a restrictive default Codex approval policy and workspace-write thread sandbox when workflow values are omitted. Codex policy values from WORKFLOW.md are passed through to the targeted app-server version.

The app-server client does not surface interactive operator prompts. Command/file approval requests are declined, unsupported client-side tool calls return structured failures, and user-input-required requests fail the run attempt after receiving an empty response. This prevents runs from waiting indefinitely for unavailable operator input.

Deployment owners still need to decide whether additional OS, container, VM, network, or credential isolation is required for their environment.

• The coding-agent cwd must be the per-issue workspace, never this source checkout.
• Workspace paths must remain under the configured workspace root.
• Workspace directory names must be derived from sanitized issue identifiers.
• Secrets must be referenced through environment variables and must not be logged.
• Hook output should be truncated when logged.
• Tracker data, issue descriptions, comments, and tool arguments are not inherently trusted.

• Conductor.Workspace rejects workspaces outside the configured root and rejects existing non-directory workspace paths.
• Hooks run with the workspace as cwd, use hooks.timeout_ms, and truncate logged output.
• Linear API keys are resolved through config/env indirection and are not emitted in logs.
• The Codex app-server subprocess is launched with the workspace as cwd; launch validation rejects mismatched cwd values.
• The optional HTTP dashboard/API starts only when server.port or CLI --port is configured. It binds to 127.0.0.1 by default, uses an in-memory generated Phoenix secret when a workflow secret is not supplied, and exposes observability plus a refresh trigger only. No HTTP authentication is added in this pass; deployments that bind a non-loopback host must provide their own network boundary.
• The optional linear_graphql Codex tool is advertised only for Linear workflows with resolved auth. It accepts one raw GraphQL query or mutation operation, rejects empty/multi-operation documents and non-object variables, and uses configured tracker auth without logging or returning the token. The tool does not implement project-scope policy narrowing beyond the workflow's configured auth.
• The optional SSH worker mode never falls back to local execution when worker.ssh_hosts is set. The orchestrator selects a host by capacity and retry affinity; remote workspace creation canonicalizes the configured root over SSH, appends only sanitized issue keys, enforces root containment, runs hooks with the remote workspace as cwd, and launches Codex over SSH stdio.

Update this file when changing:

• Codex approval or sandbox policy.
• Workspace path handling.
• Hook execution.
• Linear or GitHub credential handling.
• Client-side tools exposed to Codex app-server sessions.
• Network access, remote worker, SSH, container, or VM execution behavior.
• HTTP bind host, port, dashboard/API surface, or refresh control behavior.