Skip to content

[BUG]: session allowlist denies /tmp/kilo, the temp dir the bundled bash tool advertises #6186

Description

@maphew

Summary

The Cloud Agent session allowlist denies /tmp/kilo, but that is exactly the temp directory the bundled bash tool description tells the agent to use. Every cloud session that follows the tool guidance hits an external_directory deny.

Evidence

Injected session config (OPENCODE_CONFIG_CONTENT) observed in a live Cloud Agent container:

"external_directory": {
  "*": "deny",
  "/tmp/agent_05f6bbb9-f9de-4481-96bb-adac49526b1f/**": "allow",
  "/tmp/attachments/agent_05f6bbb9-f9de-4481-96bb-adac49526b1f/**": "allow",
  "/workspace/.../sessions/agent_05f6bbb9-f9de-4481-96bb-adac49526b1f/**": "allow",
  "/home/agent_05f6bbb9-f9de-4481-96bb-adac49526b1f/.kilocode/skills/**": "allow"
}

The bash tool description shipped in Kilo-Org/kilocode (packages/opencode/src/tool/shell/shell.txt, rendered by prompt.ts) says:

Use /tmp/kilo for temporary work outside the workspace. This directory has already been created, already exists, and is pre-approved for external directory access.

Permission evaluation log from the same session:

message=evaluated permission=external_directory pattern=/tmp/kilo/* action.permission=external_directory action.pattern=* action.action=deny action.source=project

Impact

Cloud Agent sessions receive tool guidance pointing at a denied path, producing repeated tool-call failures that are hard for users to diagnose (the error names the rule but not the attempted path).

Suggested remediation options

  1. Platform side (this repo): include the shared Kilo temp dir in the injected external_directory allowlist, for example "${os.tmpdir()}/kilo/**": "allow". This fixes all deployed CLI versions at once.
  2. CLI side (tracked upstream at [BUG]: bash tool points Cloud Agent at denied /tmp/kilo instead of session-scoped temp dir kilocode#14189): render the shell tool tmp from the session-scoped temp dir when running as a Cloud Agent.

Option 1 is the lower-friction fix; option 2 keeps the deny-by-default surface narrow. Doing either resolves the mismatch; doing both is harmless.

Activity

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

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions