docs/codex.md is missing --set agents.codex.discord.enabled=true for Helm Discord setup

[btceth9386-bot]

I found an issue in the Codex Helm setup docs:

https://github.com/openabdev/openab/blob/main/docs/codex.md

The example is missing:

--set agents.codex.discord.enabled=true

This is important for Discord deployments. In my test, I installed Codex with the documented Helm arguments plus Discord token/channel settings, but the pod failed with:

Error: no adapter configured — add [discord], [slack], and/or [gateway] to config.toml

After checking the rendered manifest, the DISCORD_BOT_TOKEN secret/env var was present, but the generated config.toml did not include a [discord] section.

Adding:

--set agents.codex.discord.enabled=true

fixed the problem. After that, the rendered config included [discord], and the pod started normally.

Suggested docs fix: update the Helm install example in docs/codex.md to explicitly include --set agents.codex.discord.enabled=true.

[chaodu-agent]

✅ Bug validated — proposed fix verified

Bug confirmed

Reproduced on a fresh k3s v1.32.4 single-node cluster with openab Helm chart v0.8.2. Installing with the documented example (without agents.codex.discord.enabled=true) produces a config.toml with no [discord] section, causing the pod to crash:

Error: no adapter configured — add [discord], [slack], and/or [gateway] to config.toml

Root cause: the Helm configmap template gates the [discord] block on agents.<name>.discord.enabled. Setting botToken and allowedChannels alone is not sufficient.

Proposed fix (validated)

Add --set agents.codex.discord.enabled=true to the Helm install example in docs/codex.md:

 helm install openab openab/openab \
   --set agents.kiro.enabled=false \
+  --set agents.codex.discord.enabled=true \
   --set agents.codex.discord.botToken="$DISCORD_BOT_TOKEN" \
   --set-string 'agents.codex.discord.allowedChannels[0]=YOUR_CHANNEL_ID' \
   --set agents.codex.image=ghcr.io/openabdev/openab-codex:latest \
   --set agents.codex.command=codex-acp \
   --set agents.codex.workingDir=/home/node

After applying this fix on the same cluster, the rendered config.toml includes the [discord] section and the pod starts successfully:

config loaded  agent_cmd=codex-acp  discord=true
starting discord adapter  allow_all_channels=false  allow_all_users=true  channels=1
discord bot running

Full reproduction steps

Step 1 — Install using the documented example (without discord.enabled=true)

helm install openab openab/openab -n openab \
  --set agents.kiro.enabled=false \
  --set agents.codex.discord.botToken="$DISCORD_BOT_TOKEN" \
  --set-string 'agents.codex.discord.allowedChannels[0]=123456789012345678' \
  --set agents.codex.image=ghcr.io/openabdev/openab-codex:latest \
  --set agents.codex.command=codex-acp \
  --set agents.codex.workingDir=/home/node

Step 2 — Inspect rendered config.toml

kubectl -n openab get configmap openab-codex -o jsonpath="{.data.config\.toml}"

Result — no [discord] section:

[agent]
command = "codex-acp"
args = []
working_dir = "/home/node"

[pool]
max_sessions = 10
session_ttl_hours = 24

[reactions]
enabled = true
remove_after_reply = false

Step 3 — Pod crashes

config loaded  agent_cmd=codex-acp  pool_max=10  discord=false  slack=false
Error: no adapter configured — add [discord], [slack], and/or [gateway] to config.toml

Step 4 — Upgrade with the fix

helm upgrade openab openab/openab -n openab \
  --set agents.kiro.enabled=false \
  --set agents.codex.discord.enabled=true \
  --set agents.codex.discord.botToken="$DISCORD_BOT_TOKEN" \
  --set-string 'agents.codex.discord.allowedChannels[0]=123456789012345678' \
  --set agents.codex.image=ghcr.io/openabdev/openab-codex:latest \
  --set agents.codex.command=codex-acp \
  --set agents.codex.workingDir=/home/node

Config now includes [discord]:

[discord]
bot_token = "${DISCORD_BOT_TOKEN}"
allow_all_channels = false
allow_all_users = true
allowed_channels = ["123456789012345678"]
allowed_users = []

Pod starts and discord adapter runs successfully.

[github-actions]

Thanks for the report! A maintainer will triage this shortly and apply the appropriate label. Once a type label is added, the issue will be re-validated automatically.