From 2fdd2a60cf00ca62e67fa8ae019e4680f98063ca Mon Sep 17 00:00:00 2001 From: chaodu-agent <274062505+chaodu-agent@users.noreply.github.com> Date: Wed, 28 Oct 2026 19:24:16 +0000 Subject: [PATCH 1/4] docs: note Kiro API-key MCP issue and fix multibot thread-owner docs - kiro.md: known-issue note for upstream kirodotdev/Kiro#11777 with tested GitHub OAuth workaround (#1576) - discord.md: allowed_role_ids table now matches MultibotMentions code; thread owner also needs @mention once another bot posted (#1566) Verification: docs-only; no local build (CI on PR). --- docs/discord.md | 7 ++++--- docs/kiro.md | 34 ++++++++++++++++++++++++++++++++++ 2 files changed, 38 insertions(+), 3 deletions(-) diff --git a/docs/discord.md b/docs/discord.md index e179d8a1c..e39610596 100644 --- a/docs/discord.md +++ b/docs/discord.md @@ -105,7 +105,7 @@ Controls whether the bot requires @mention in threads. |---|---| | `"involved"` | Respond in threads the bot owns or has participated in without @mention. Main channel always requires @mention. | | `"mentions"` | Always require @mention, even in the bot's own threads. | -| `"multibot-mentions"` (default) | Same as `involved` in single-bot threads. In threads where other bots have also posted, requires @mention — prevents all bots from responding to every message. | +| `"multibot-mentions"` (default) | Same as `involved` in single-bot threads. In threads where other bots have also posted, requires @mention — prevents all bots from responding to every message. This applies to the thread owner too: once another bot has posted in the thread, the owner also needs an @mention. | #### Comparison @@ -161,10 +161,11 @@ When `allow_user_messages = "multibot-mentions"` is set alongside `allowed_role_ | Action | Result | |--------|--------| | `@Role review this` in a channel | All bots trigger (role mention = explicit mention) | -| Follow-up in the thread without @mention | Only the thread owner responds (multibot gate kicks in) | +| Follow-up in the thread without @mention | No bot responds once more than one bot has posted in the thread, including the thread owner (multibot gate kicks in) | +| `@Bot follow up` in the thread | Only the mentioned bot responds | | `@Role follow up` in the thread | All bots respond again | -This gives the best of both worlds: one role mention to summon all bots, but subsequent messages in the thread don't cause all bots to pile on. +This gives the best of both worlds: one role mention to summon all bots, but subsequent messages in the thread don't cause all bots to pile on. In a multi-bot thread, address each follow-up with an @mention of the bot (or role) you want to answer. --- diff --git a/docs/kiro.md b/docs/kiro.md index 4601ee43e..946931c25 100644 --- a/docs/kiro.md +++ b/docs/kiro.md @@ -141,6 +141,40 @@ sequenceDiagram This makes the entire Kiro deployment **zero-touch** — fully automated with no login step required. +#### Known issue: MCP and web tools disabled with `KIRO_API_KEY` + +> **Temporary note.** Remove this section once the upstream bug is fixed and a fixed Kiro CLI version has been tested. + +An upstream Kiro bug ([kirodotdev/Kiro#11777](https://github.com/kirodotdev/Kiro/issues/11777), reproduced on Kiro CLI 2.33.1) can leave an API-key-authenticated agent where chat works but MCP servers and web tools are unavailable. A successful `kiro-cli whoami` or a normal chat reply does not prove that MCP loaded. Typical symptoms in the Kiro logs: + +```text +GetProfile failed on all endpoints for API key +Failed to get governance config from API — MCP disabled, web tools disabled +``` + +ACP may also emit `_kiro.dev/mcp/governance_disabled` with `apiFailure: true`. + +**Workaround (tested): GitHub OAuth login instead of the API key** + +1. Inside the persistent agent home, as the agent user, log in without the API key in the environment and select **Use with GitHub** in the menu: + + ```bash + env -u KIRO_API_KEY kiro-cli login --use-device-flow + ``` + +2. Confirm the login method (not just the email): + + ```bash + env -u KIRO_API_KEY kiro-cli whoami # expect "Logged in with GitHub" + ``` + +3. Stop passing `KIRO_API_KEY` to the agent subprocess: remove it from `[agent].env` (and from `inherit_env` or any wrapper that re-adds it). Unsetting it only in the login shell is not enough if OpenAB injects it again when spawning Kiro. If `config.toml` is generated, fix the generator too. +4. Make sure `~/.kiro/` and `~/.local/share/kiro-cli/` are persisted (see [Persisted Paths](#persisted-paths-pvc)). +5. Restart OpenAB and start a fresh session so no API-key-authenticated Kiro process is reused. +6. Verify that MCP servers initialize and that a real read-only tool call succeeds. + +When reporting this issue, include the image tag or digest and `kiro-cli --version`. Floating `nightly` tags follow the latest upstream CLI, so behavior can change without any OpenAB config change. See [#1576](https://github.com/openabdev/openab/issues/1576). + ### Alternative: OAuth Device Flow (Legacy) If you cannot use an API key, Kiro CLI falls back to the OAuth device code flow. The PVC persists tokens across pod restarts. From 11c97bbde97d19281f21f0780f136f92bf9eb80d Mon Sep 17 00:00:00 2001 From: chaodu-agent <274062505+chaodu-agent@users.noreply.github.com> Date: Thu, 29 Oct 2026 07:22:12 -0400 Subject: [PATCH 2/4] docs(kiro): add Helm secretEnv step and link Known issue from API key section - Known issue step 3: for Helm installs, also remove KIRO_API_KEY from agents..secretEnv, since the chart adds those keys to inherit_env. - API key section: link to the Known issue section for MCP/web tool failures. Checks: anchor #known-issue-mcp-and-web-tools-disabled-with-kiro_api_key verified against heading slug on macmini; no markdown lint workflow in repo. --- docs/kiro.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/docs/kiro.md b/docs/kiro.md index 946931c25..0cea37a85 100644 --- a/docs/kiro.md +++ b/docs/kiro.md @@ -55,6 +55,8 @@ To override a single agent's image instead of the global tag: Kiro CLI supports API key authentication via the `KIRO_API_KEY` environment variable. This is the **recommended** approach — it requires no manual OAuth login and is fully managed by AWS Secrets Manager. +If MCP servers or web tools are disabled with this setup, see [Known issue: MCP and web tools disabled with `KIRO_API_KEY`](#known-issue-mcp-and-web-tools-disabled-with-kiro_api_key). + #### Setup Steps 1. **Enable API Keys in AWS Console** — Go to your AWS Console and search for "Kiro". Enable the API Keys feature. This option is only available through the AWS Console. @@ -168,7 +170,7 @@ ACP may also emit `_kiro.dev/mcp/governance_disabled` with `apiFailure: true`. env -u KIRO_API_KEY kiro-cli whoami # expect "Logged in with GitHub" ``` -3. Stop passing `KIRO_API_KEY` to the agent subprocess: remove it from `[agent].env` (and from `inherit_env` or any wrapper that re-adds it). Unsetting it only in the login shell is not enough if OpenAB injects it again when spawning Kiro. If `config.toml` is generated, fix the generator too. +3. Stop passing `KIRO_API_KEY` to the agent subprocess: remove it from `[agent].env` (and from `inherit_env` or any wrapper that re-adds it). Unsetting it only in the login shell is not enough if OpenAB injects it again when spawning Kiro. If `config.toml` is generated, fix the generator too. For Helm installs, also remove the `KIRO_API_KEY` entry from `agents..secretEnv`, because the chart adds those keys to `inherit_env`. 4. Make sure `~/.kiro/` and `~/.local/share/kiro-cli/` are persisted (see [Persisted Paths](#persisted-paths-pvc)). 5. Restart OpenAB and start a fresh session so no API-key-authenticated Kiro process is reused. 6. Verify that MCP servers initialize and that a real read-only tool call succeeds. From 2ea54544d755741e340471c31d9c15638becb2ca Mon Sep 17 00:00:00 2001 From: chaodu-agent <274062505+chaodu-agent@users.noreply.github.com> Date: Thu, 29 Oct 2026 11:27:29 -0400 Subject: [PATCH 3/4] docs: correct Helm secretEnv step and flag thread-owner rule as tracked - kiro.md: the Helm step said the chart adds secretEnv keys to inherit_env. The chart does not do that. Rewrite it to say the key is removed from agents..secretEnv (no container env injection) and must not be in inherit_env. - discord.md: mark the multibot-mentions thread-owner rule as current behavior tracked in #1566, which calls it a bug and may change. Rule itself unchanged. Checks: anchors #persisted-paths-pvc, #known-issue-mcp-and-web-tools-disabled-with-kiro_api_key, #multi-bot-setup resolve to headings on their pages. Repo has no markdownlint config or CI job, and markdownlint is not installed on macmini, so no lint run. --- docs/discord.md | 4 ++++ docs/kiro.md | 2 +- 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/discord.md b/docs/discord.md index e39610596..d22fe8fca 100644 --- a/docs/discord.md +++ b/docs/discord.md @@ -107,6 +107,8 @@ Controls whether the bot requires @mention in threads. | `"mentions"` | Always require @mention, even in the bot's own threads. | | `"multibot-mentions"` (default) | Same as `involved` in single-bot threads. In threads where other bots have also posted, requires @mention — prevents all bots from responding to every message. This applies to the thread owner too: once another bot has posted in the thread, the owner also needs an @mention. | +> **Note:** The thread-owner rule in `"multibot-mentions"` describes current behavior. It is tracked in [#1566](https://github.com/openabdev/openab/issues/1566), which calls it a bug, so it may change. + #### Comparison | Scenario | `involved` | `mentions` | `multibot-mentions` | @@ -167,6 +169,8 @@ When `allow_user_messages = "multibot-mentions"` is set alongside `allowed_role_ This gives the best of both worlds: one role mention to summon all bots, but subsequent messages in the thread don't cause all bots to pile on. In a multi-bot thread, address each follow-up with an @mention of the bot (or role) you want to answer. +> **Note:** The owner-needs-@mention behavior above describes current behavior. It is tracked in [#1566](https://github.com/openabdev/openab/issues/1566), which calls it a bug, so it may change. + --- ## @Mention Behavior diff --git a/docs/kiro.md b/docs/kiro.md index 0cea37a85..ff3587f65 100644 --- a/docs/kiro.md +++ b/docs/kiro.md @@ -170,7 +170,7 @@ ACP may also emit `_kiro.dev/mcp/governance_disabled` with `apiFailure: true`. env -u KIRO_API_KEY kiro-cli whoami # expect "Logged in with GitHub" ``` -3. Stop passing `KIRO_API_KEY` to the agent subprocess: remove it from `[agent].env` (and from `inherit_env` or any wrapper that re-adds it). Unsetting it only in the login shell is not enough if OpenAB injects it again when spawning Kiro. If `config.toml` is generated, fix the generator too. For Helm installs, also remove the `KIRO_API_KEY` entry from `agents..secretEnv`, because the chart adds those keys to `inherit_env`. +3. Stop passing `KIRO_API_KEY` to the agent subprocess: remove it from `[agent].env` (and from `inherit_env` or any wrapper that re-adds it). Unsetting it only in the login shell is not enough if OpenAB injects it again when spawning Kiro. If `config.toml` is generated, fix the generator too. For Helm installs, also remove the `KIRO_API_KEY` entry from `agents..secretEnv`, so the key is no longer injected into the container environment. The agent subprocess only receives it if `inherit_env` lists it, so make sure `inherit_env` does not list `KIRO_API_KEY`. 4. Make sure `~/.kiro/` and `~/.local/share/kiro-cli/` are persisted (see [Persisted Paths](#persisted-paths-pvc)). 5. Restart OpenAB and start a fresh session so no API-key-authenticated Kiro process is reused. 6. Verify that MCP servers initialize and that a real read-only tool call succeeds. From b1862a6d92da53870de12560773707c8a4efb57e Mon Sep 17 00:00:00 2001 From: chaodu-agent <274062505+chaodu-agent@users.noreply.github.com> Date: Thu, 29 Oct 2026 11:34:16 -0400 Subject: [PATCH 4/4] docs(kiro): name [agent].env as a second source of KIRO_API_KEY Step 3 said the agent subprocess only receives KIRO_API_KEY if inherit_env lists it. [agent].env also forwards it, so name both sources. Checks: docs-only; markdown anchors unchanged; diff touches only docs/kiro.md. --- docs/kiro.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/kiro.md b/docs/kiro.md index ff3587f65..60813272d 100644 --- a/docs/kiro.md +++ b/docs/kiro.md @@ -170,7 +170,7 @@ ACP may also emit `_kiro.dev/mcp/governance_disabled` with `apiFailure: true`. env -u KIRO_API_KEY kiro-cli whoami # expect "Logged in with GitHub" ``` -3. Stop passing `KIRO_API_KEY` to the agent subprocess: remove it from `[agent].env` (and from `inherit_env` or any wrapper that re-adds it). Unsetting it only in the login shell is not enough if OpenAB injects it again when spawning Kiro. If `config.toml` is generated, fix the generator too. For Helm installs, also remove the `KIRO_API_KEY` entry from `agents..secretEnv`, so the key is no longer injected into the container environment. The agent subprocess only receives it if `inherit_env` lists it, so make sure `inherit_env` does not list `KIRO_API_KEY`. +3. Stop passing `KIRO_API_KEY` to the agent subprocess: remove it from `[agent].env` (and from `inherit_env` or any wrapper that re-adds it). Unsetting it only in the login shell is not enough if OpenAB injects it again when spawning Kiro. If `config.toml` is generated, fix the generator too. For Helm installs, also remove the `KIRO_API_KEY` entry from `agents..secretEnv`, so the key is no longer injected into the container environment. The agent subprocess only receives it if `[agent].env` or `inherit_env` lists it, so make sure neither does. 4. Make sure `~/.kiro/` and `~/.local/share/kiro-cli/` are persisted (see [Persisted Paths](#persisted-paths-pvc)). 5. Restart OpenAB and start a fresh session so no API-key-authenticated Kiro process is reused. 6. Verify that MCP servers initialize and that a real read-only tool call succeeds.