Repository navigation
docs: auto-sync cloud-agent with merged PRs (through 2026-10-25) - #15141
github-actions[bot] wants to merge 10 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Code Review SummaryStatus: 6 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)SUGGESTION
Files Reviewed (1 file)
Fix these issues in Kilo Cloud Previous Review Summaries (4 snapshots, latest commit 907b3b9)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit 907b3b9)Status: 3 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)SUGGESTION
Files Reviewed (1 file)
Fix these issues in Kilo Cloud Previous review (commit c995f82)Status: 3 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)SUGGESTION
Files Reviewed (1 file)
Previous review (commit a10999c)Status: 1 Issue Found | Recommendation: Address before merge Overview
Issue Details (click to expand)SUGGESTION
Files Reviewed (1 files)
Fix these issues in Kilo Cloud Previous review (commit f575fc2)Status: No Issues Found | Recommendation: Merge Files Reviewed (1 files)
Reviewed by deepseek-flash-latest · Input: 40.1K · Output: 9.9K · Cached: 331.9K Review guidance: REVIEW.md from base branch |
|
|
||
| ## Previewing a running app | ||
|
|
||
| You can preview a web app running inside a Cloud Agent session's sandbox. When a session serves an app on a port, the web interface shows a preview button and preview links, and selecting one opens the running app in a new browser tab. Each preview is served from its own hostname that targets the session's workspace and port, so different sessions and ports do not collide. |
There was a problem hiding this comment.
SUGGESTION: Consider documenting who can reach a preview URL
This paragraph explains that each preview is served from its own hostname targeting the session's workspace and port, but it does not say whether that URL requires a Kilo sign-in or is reachable by anyone holding the link. Since the preview exposes a web app running inside the sandbox, one sentence about the access model (and whether previews should be treated as shareable/public) would help readers decide what they expose there.
|
|
||
| ### Run as webhook creator | ||
|
|
||
| By default, organization triggers run as the organization webhook bot. When you create an organization trigger, you can instead select **Run as webhook creator** so each session runs with your identity. Organization billing and repository scope stay with the organization. |
There was a problem hiding this comment.
SUGGESTION: Mention that shared organization settings still apply
This explains that each session runs with your identity, but not that organization profiles and repository settings remain shared and are resolved at run time. Members who can edit those settings can therefore affect what a creator-run session executes under your identity. One sentence about that trust boundary would help readers decide whether to opt in.
|
|
||
| By default, organization triggers run as the organization webhook bot. When you create an organization trigger, you can instead select **Run as webhook creator** so each session runs with your identity. Organization billing and repository scope stay with the organization. | ||
|
|
||
| This is a create-time choice and cannot be changed later. Only you, the creator, can edit a creator-run trigger or run it on demand. Existing triggers keep using the organization webhook bot; create a new trigger to use creator mode. |
There was a problem hiding this comment.
SUGGESTION: Clarify where "run it on demand" applies
Creator-run mode also covers scheduled triggers, and only scheduled triggers have an invoke action — the section below states that webhook triggers have no invoke action. Consider saying that you can run a creator-run scheduled trigger on demand, so readers do not look for a Run action on creator-run webhook triggers.
|
|
||
| - A sandbox size | ||
| - One setup script | ||
| - Variables, including secrets (encrypted at rest) |
There was a problem hiding this comment.
SUGGESTION: Clarify which repository environment values are encrypted
This bullet groups variables and secrets under "encrypted at rest", but line 86 says "New and replaced variable values are encrypted; values stored before encryption remain compatible", and the profiles section (lines 167-168) deliberately distinguishes plaintext environment variables from encrypted secrets. Readers deciding where to put a sensitive value cannot tell whether plain variables in a repository environment are stored encrypted now, and what the legacy-values caveat means for them. One sentence naming which fields are encrypted would settle it.
|
|
||
| Open **Env** beside a repository to create or edit its environment. In an organization, owners and admins can manage repository environments; other members see them read-only. | ||
|
|
||
| When a repository environment applies, its setup script replaces the setup commands from the selected [agent environment profile](#agent-environment-profiles). The profile's variables and agent settings still apply. A warning beside the profile picker explains when a profile's setup is replaced. |
There was a problem hiding this comment.
SUGGESTION: State how repository environment values interact with profile variables and per-session overrides
This paragraph explains that the setup script replaces the profile's setup commands and that "the profile's variables ... still apply", but a repository environment also stores variables. If the repository environment and the profile define the same key, the page does not say which wins. It also does not connect to the later section stating that per-session env vars and startup commands override the selected profile (line 187) — that text now predates the repository environment layer and does not say how a session-level setup command relates to a repository environment's setup script. A short precedence statement would avoid readers guessing.
|
|
||
| ### Request body validation | ||
|
|
||
| Webhook triggers can validate each request body against a JSON Schema before the request is captured. When a body does not match the schema, Kilo rejects it with HTTP 400 and does not capture or queue it. |
There was a problem hiding this comment.
SUGGESTION: Explain what validation does with non-JSON bodies
Triggers accept non-JSON content types, and the template variables section says {{bodyJson}} falls back to the raw body when the payload is not parseable JSON, so some requests reaching this validator will not be JSON. This paragraph does not say whether a schema applies to those requests (rejected with 400, skipped, or treated as a parse failure). The next paragraph also lists "value limits" without saying what they are. Naming the accepted body shape and the non-JSON behaviour would make the schema editor's scope clear.
Automated docs sync — 2026-10-25
This PR keeps kilo.ai/docs in sync with features merged to Kilo-Org/cloud and Kilo-Org/kilocode. Every change below links to the merged PR it documents.
2026-10-24T07:03:19.791Z→2026-10-25T07:03:39.767ZSurface:
cloud-agentother(the explicit other prefixes are listed under other.docs). The cloud surfaces are derived the same way from the Kilo-Org/cloud layout: cloud-mobile = apps/mobile/, cloud-web = apps/web/, cloud-extension = apps/extension/, and cloud-agent = the cloud-agent packages under packages/ (packages/cloud-agent-sdk/ + packages/cloud-agent-profile/). A cloud source names its repository while a bare string still means this repository. The pages under packages/kilo-docs/pages/collaborate/ document the cloud web app (app.kilo.ai: teams dashboard, billing, SSO, adoption dashboard), so they route to cloud-web. No page under packages/kilo-docs/pages/ documents the browser side-panel extension yet, so cloud-extension lists no docs prefix..github/docs-sync/surfaces.jsoncli,vscode,jetbrains,gateway,web,cloud-mobile,cloud-web,cloud-extension,cloud-agent,otherpackages/cloud-agent-sdk/(Kilo-Org/cloud),packages/cloud-agent-profile/(Kilo-Org/cloud)packages/kilo-docs/pages/code-with-ai/platforms/cloud-agent.mdother:packages/kilo-docs/pages/community/,packages/kilo-docs/pages/contributing/,packages/kilo-docs/LEARNINGS.md,docs/Kilo-Org/cloud; the workflow needs a token withcontents: readon that repository (repository secretCROSS_REPO_ACCESS_TOKEN, exposed to the upsert step asCLOUD_REPO_TOKEN).cloud-agentare ranked fromKilo-Org/cloudgit history overpackages/cloud-agent-sdk/,packages/cloud-agent-profile/(a commit 180 days old counts half as much, half-life 180 days). Bots (author type "Bot" or a login matching /[bot]$/i) and people without admin, write, or maintain permission are excluded.Changes
Pending — will retry
None.
Considered, no docs change needed
(bot) Generated by the docs-sync workflow. Humans review and merge; while this PR stays open, the next daily run appends new changes here. Branch:
docs/auto-sync-2026-10-25.