Repository navigation
docs: auto-sync cloud-agent with merged PRs (through 2026-10-31) - #15141
github-actions[bot] wants to merge 18 commits into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Code Review SummaryStatus: 13 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (1 file)
Fix these issues in Kilo Cloud Previous Review Summaries (8 snapshots, latest commit 2e66333)Current summary above is authoritative. Previous snapshots are kept for context only. Previous review (commit 2e66333)Status: 13 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (1 file)
Fix these issues in Kilo Cloud Previous review (commit 98dd158)Status: 12 Issues Found | Recommendation: Address before merge Overview
Issue Details (click to expand)WARNING
SUGGESTION
Files Reviewed (1 file)
Previous review (commit 2bf9656)Status: 7 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 c71bd73)Status: 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 (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: 39.4K · Output: 4.6K · Cached: 237.6K Review guidance: REVIEW.md from base branch |
github-actions
Bot
changed the title
github-actions
Bot
changed the title
![kilo-code-bot[bot]](https://avatars.githubusercontent.com/in/2193792?s=60&v=4){kind=small}
|
|
||
| ## 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.
github-actions
Bot
changed the title
github-actions
Bot
changed the title
github-actions
Bot
changed the title
|
|
||
| ### 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.
github-actions
Bot
changed the title
github-actions
Bot
changed the title
|
|
||
| - 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.
github-actions
Bot
changed the title
github-actions
Bot
changed the title
|
|
||
| ### Skills from skills.sh | ||
|
|
||
| An [agent environment profile](#agent-environment-profiles) can also install public skills from [skills.sh](https://skills.sh). Open the profile's **Skills** tab and add a qualified reference such as `anthropics/skills@frontend-design` or a skills.sh skill URL. Cloud Agent installs the referenced skill and its companion files when it prepares a session, so the contents always come from upstream rather than a snapshot saved in the profile. Because there is no Markdown snapshot to edit, you enable, disable, or delete a referenced skill instead of editing it. Manual skills and ZIP uploads work the same as before. |
There was a problem hiding this comment.
SUGGESTION: Note that referenced skill content comes from a third party and can change upstream
This paragraph correctly says the contents "always come from upstream", but it does not tell readers that a skills.sh reference is resolved at session prep and can therefore change without anyone editing the profile, and that an organization-owned profile shares those references with every member who selects it. Because the skill's instructions and companion files are what the agent actually uses, one sentence asking readers to review the upstream skill before adding it (similar to the webhook/prompt-injection caution later on this page) would make the trust model explicit.
github-actions
Bot
changed the title
|
|
||
| ## Delegating to child sessions | ||
|
|
||
| A Cloud Agent session that you start interactively — from the web app, the desktop app, or Agent Manager — can launch child Cloud Agent sessions to work on part of the task. Each child runs in its own isolated sandbox. |
There was a problem hiding this comment.
WARNING: This conflicts with the page's own container model
Above, the page says "Each user receives an isolated Linux container" (line 112) and "All Cloud Agent chats share a single container instance" (line 114), but this says each child session runs in its own isolated sandbox. Either child sessions share the parent's container or they get separate ones; as written, readers cannot tell which is true. It is also unclear how a child's work reaches the parent when the child has its own sandbox and checkout (separate branch, pull request, or result message?). Consider reconciling line 114 and describing how child results return to the parent.
| A session cannot launch child sessions when any of these apply: | ||
|
|
||
| - **It is itself a child.** Child sessions cannot delegate further, so delegation stays one level deep. | ||
| - **It runs on a shared sandbox.** Shared sandboxes do not support child sessions. Start the session on an isolated sandbox instead. |
There was a problem hiding this comment.
SUGGESTION: Define "shared sandbox"
"Shared sandbox" is not defined anywhere on this page, and the sandbox selection section (line 315) only describes providers and an Automatic option, so readers told to "start the session on an isolated sandbox instead" have no way to tell which choice supports child sessions. Consider naming the sandbox option(s) that do, or linking to the section that explains the difference between shared and isolated sandboxes.
|
|
||
| - **It is itself a child.** Child sessions cannot delegate further, so delegation stays one level deep. | ||
| - **It runs on a shared sandbox.** Shared sandboxes do not support child sessions. Start the session on an isolated sandbox instead. | ||
| - **It was started by a bot.** Sessions created by code reviews, security reviews, and triggers never get this capability. |
There was a problem hiding this comment.
SUGGESTION: Cover CLI-started sessions in the eligibility rules
The page documents kilo cloud start and kilo cloud send above (lines 92-108), but sessions started that way are neither started interactively from the surfaces listed on line 133 nor created by a bot, so this list of exclusions leaves it unclear whether they can launch child sessions. Add CLI-started sessions to the list, or state explicitly whether they get the capability.
| - **It runs on a shared sandbox.** Shared sandboxes do not support child sessions. Start the session on an isolated sandbox instead. | ||
| - **It was started by a bot.** Sessions created by code reviews, security reviews, and triggers never get this capability. | ||
|
|
||
| Sessions created before this capability became available keep it disabled. Start a new session to launch child sessions. |
There was a problem hiding this comment.
SUGGESTION: State the cutover for existing sessions
"Sessions created before this capability became available" gives readers no way to know whether their session is in that group, because the capability has no date, version, or UI marker on this page. Consider naming the rollout cutover (for example a date) or saying that sessions created before it can only get the capability by starting a new session.
|
|
||
| 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. | ||
|
|
||
| Creator-run sessions also resolve GitHub credentials with your own authorization when it is available, so commits and pushes are attributed to your GitHub identity instead of the organization bot. This matches interactive Cloud Agent web sessions. If your account has not authorized the GitHub App, or the repository permissions do not allow it, the session falls back to the installation bot. Organization-bot triggers keep using the organization bot identity. |
There was a problem hiding this comment.
WARNING: Reconcile creator-run identity with the organization-trigger description
This says creator-run organization triggers commit and push as the creator's GitHub identity, but the Trigger Limits section (line 348) still states that organization triggers "Execute in dedicated compute resources as a bot user, similar to Code Review sessions". That is no longer accurate for creator-run triggers and contradicts this paragraph. The paragraph also switches between "organization webhook bot", "organization bot", and "installation bot" without defining the last one; consider using one term and cross-referencing the Integrations page for the GitHub App authorization you mention.
github-actions
Bot
changed the title
| ## Reviewing changes | ||
|
|
||
| Select **Changes** in the chat header to open the worktree's saved change summary, including file status and lines added and removed. The view shows the comparison's base branch and when the summary was saved, with the changed-file list on the left and the selected file's diff on the right. Selecting another file replaces the diff in place instead of opening a new tab. Refresh to load the latest saved summary; reloading reads the latest saved revision without starting the workspace. Large summaries can be partial, with some files or line counts omitted. | ||
| Select **Changes** in the chat header to open the worktree's saved change summary. It compares your work two ways: **Uncommitted** first, which shows changes in the working tree since the last commit, and **Against base branch** second, which shows the commits on the worktree branch since it diverged from the base branch. A file you committed and then edited further appears under both. Each file tab is labelled with its comparison, so you can open the same path in either one. |
There was a problem hiding this comment.
SUGGESTION: Use consistent terminology for the file list
This says "Each file tab is labelled with its comparison", but the next paragraph describes the changed-file list on the left and states that selecting another file "replaces the diff in place instead of opening a new tab". Calling the entries "tabs" contradicts that. Consider "each changed-file entry is labelled with its comparison" (or clarify whether the tabs are the two comparison tabs).
github-actions
Bot
changed the title
Automated docs sync — 2026-10-31
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-30T07:01:39.938Z→2026-10-31T07:01:29.877ZSurface:
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
permissionsarray with renamedshell/subagentactions and adds packages/kilo-vscode/test/permission-rules.test.ts, but the current tree's Auto-Approve UI uses the documentedpermissionobject withbash/taskand permission-utils.ts has different signatures; settings/tabs.ts and that test path are absent. Current behavior is already documented in pages/getting-started/settings/auto-approving-actions.md.(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-31.