Feature request: custom environment / Docker image support for CCR (Remote Triggers)

Problem

CCR (Claude Code Remote) sessions currently run in a single fixed environment (claude-code-default, env_01DM8B4R17aDw5t8H9TCzdhy). There is no way to bring a custom Docker image or pre-configure additional tooling.

This is a blocker for any skill or automation that requires build tools not present in the default environment — such as Bazel, Java, specific SDK versions, or proprietary CLI tools.

Concrete use case

We have a skill (sre-incident-analysis) that includes a code-fix pipeline:

1. Identifies root cause of a production incident from New Relic logs
2. Locates the file and proposes a fix
3. Applies the fix, runs unit tests via bazel test, verifies build via bazel build //...
4. Opens a PR

Steps 3 requires Bazel + Java. In the default CCR environment, neither is available. Our current workaround is to skip the build verification step entirely and delegate it to GitHub Actions CI — which works but removes a quality gate that matters (catching compilation errors before the PR is even opened).

Installing Bazel at runtime inside a CCR session is theoretically possible but takes 5–10 minutes per run and is fragile (network dependencies, version drift). A pre-built image would be instantaneous.

Expected behavior

The Remote Trigger API (or the environment configuration UI) should allow specifying a custom Docker image or a pre-built environment:

Option A — Custom Docker image per trigger:

{
  "job_config": {
    "ccr": {
      "environment_id": "env_custom",
      "container_image": "ghcr.io/myorg/claude-code-bazel:latest",
      "session_context": { ... }
    }
  }
}

Option B — Organization-managed environments:
Allow organizations to register custom environments (Docker images) through a UI or API, then reference them by ID in triggers — similar to how CI/CD platforms (GitHub Actions, CircleCI) let you specify a container per job.

Why this matters

Teams with Java/Bazel monorepos, Python-heavy data pipelines, or any build system beyond what comes in the default environment cannot fully automate their code-fix workflows in CCR today. Custom environments would unlock end-to-end autonomous fix + verify + PR pipelines for a much broader set of tech stacks.