[FEATURE] Allow setting workingDir on BYO Agent deployment

[djmcgreal-cc]

Problem Statement

spec.byo.deployment lets users specify image, cmd, args, env, volumes, volumeMounts, resources, securityContext, and most other PodSpec-equivalent fields — but there's no workingDir. Kubernetes' container spec has it; the kagent BYO schema doesn't expose it.

This breaks BYO images whose entrypoint resolves paths relative to CWD. Concrete example: a Bun-built app whose HTML manifest stores chunk paths like ./index-abcdef.js. Bun's HTML loader resolves these relative to CWD, so without setting CWD to the mount directory the app crashes at startup with:

TypeError: Bundled file "./index-abcdef.js" not found.

A standalone Deployment works fine (workingDir: /app), but converting the same image to BYO breaks because the field is unreachable. The current workaround is to wrap cmd/args in sh -c "cd /app && exec <real-cmd>", which adds a shell layer to every BYO invocation and obscures PID 1.

Proposed Solution

Add workingDir as an optional string under spec.byo.deployment, mapping directly to container.workingDir in the generated Deployment:

spec:
  type: BYO
  byo:
    deployment:
      image: oven/bun:1.2-alpine
      cmd: bun
      args: ["/app/index.js"]
      workingDir: /app   # <-- new
      volumeMounts:
        - { name: app, mountPath: /app, readOnly: true }

Alternatives Considered

• Shell wrapper (sh -c "cd /app && exec ..."): works, but adds an extra process, hides the real binary in process listings, and breaks signal handling unless exec is remembered.
• Custom image with WORKDIR /app in the Dockerfile: requires maintaining a derivative image just to set one field that the underlying Kubernetes spec already supports.

Affected Services

Controller Service

Additional Context

Tested on kagent v0.9.4 (CRD apiVersion kagent.dev/v1alpha2). The BYO schema already passes through image, cmd, args, env, volumes, volumeMounts, resources, securityContext, podSecurityContext, serviceAccountName, imagePullSecrets, imagePullPolicy, nodeSelector, tolerations, affinity, annotations, labels, replicas, extraContainers — so adding one more PodSpec field is a small, mechanical change.

Willing to contribute?

Open to it.