Skip to content

[FEATURE] Allow setting workingDir on BYO Agent deployment #1932

Closed

Description

@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.

Activity

  1. added a commit that references this issue on Jun 6, 2026
    14d6840
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions