Skip to content

coze-cli-case-study.md

Latest commit

 

History

History
100 lines (69 loc) · 5.28 KB

coze-cli-case-study.md

File metadata and controls

100 lines (69 loc) · 5.28 KB
Raw
layout default
title Coze CLI Global Skill Routing Case Study
description A sanitized Windows case study of global Coze CLI Skill installation, cross-host propagation, bridge snapshots, and credential scope expansion.
permalink /coze-cli-case-study/

Coze CLI Case Study

Purpose

This is a sanitized configuration-risk case study, not a claim that every Coze CLI version or installation behaves identically. The observations below were verified on one Windows installation of @coze/cli version 0.3.4 on 2026-07-13. Product behavior may change; always inspect the installed version.

This page is included because it preserves a verified attribution chain for a broader class of Agent CLI scope failures. Coze CLI is the observed sample, not the problem category. The same pattern can occur with any external CLI, MCP server, plugin, installer, or Agent platform that writes global routing rules into a host-visible Skill directory.

Observed chain

  1. @coze/cli was installed globally through npm.
  2. Its package lifecycle included a post-install path that invoked Skill installation or synchronization.
  3. A using-coze-cli Skill appeared in a shared user-level Agent Skill pool.
  4. The Skill description covered software development, Agent, workflow, and Skill work without requiring the user to explicitly name Coze.
  5. A second Agent host exposed the same physical Skill through a Windows Junction.
  6. A local bridge stored a process-environment snapshot and used it for child-agent environments.
  7. User-level secrets present in the parent environment therefore became available to unrelated child tasks.

The result was a routing and scope-control failure. It does not establish that credential values were transmitted to a remote service.

Attribution of using-coze-cli

In the observed installation, using-coze-cli was not handwritten by Codex and there was no evidence of a manual local edit to the global Skill file.

The first observed creation path was the Coze desktop bridge installer. On 2026-07-05 at about 12:28:47 +08:00, a coze-cli-installer bridge process began installing @coze/cli@latest. That installation placed Coze CLI's bundled Skill content into the user-level Agent Skill pool and made it visible to Agent hosts on the machine. The installed CLI version in that first chain was 0.3.3.

The later observed modification path was a CLI upgrade and resync. On 2026-07-06 at about 20:52:30 +08:00, Codex ran coze auth status as part of a troubleshooting flow. That command triggered the Coze CLI update path; the CLI upgraded to 0.3.4, and the package lifecycle resynchronized the bundled using-coze-cli Skill. In this chain, Codex was an indirect trigger of the upgrade check, not the author or editor of the Skill content.

The content provenance was package-based: the global Skill file matched the @coze/cli package template byte-for-byte.

Package template: @coze/cli/skills/using-coze-cli/SKILL.md
Global copy:      ~/.agents/skills/using-coze-cli/SKILL.md
Size:             30,964 bytes
SHA-256:          501BBEA6AA5044A12F656DE1D5A02BA67B5694D5A034BA13B3B78B03ED77B537

The @coze/cli package metadata declared an author contact under a bytedance.com domain, but the published package did not include a source repository URL or per-file authorship metadata. The evidence therefore supports attribution to the @coze/cli published package and its install/update lifecycle, not to a specific individual.

Read-only verification on Windows

Check the globally installed package:

npm ls -g @coze/cli --depth=0
$npmRoot = npm root -g
$package = Get-Content "$npmRoot\@coze\cli\package.json" -Raw | ConvertFrom-Json
$package.version
$package.scripts.postinstall

Compare the package template with the global Skill copy:

$npmRoot = npm root -g
Get-FileHash "$npmRoot\@coze\cli\skills\using-coze-cli\SKILL.md" -Algorithm SHA256
Get-FileHash "$HOME\.agents\skills\using-coze-cli\SKILL.md" -Algorithm SHA256

List global Agent Skill locations without opening credentials:

Get-ChildItem "$HOME\.agents\skills" -Directory -ErrorAction SilentlyContinue
Get-ChildItem "$HOME\.trae\skills" -Directory -ErrorAction SilentlyContinue |
  Select-Object Name, LinkType, Target

Check whether a bridge snapshot exists. Do not print its contents in a shared terminal or issue:

Get-Item "$HOME\.coze\bridge\agent-env.json" -ErrorAction SilentlyContinue |
  Select-Object FullName, Length, LastWriteTime

The repository tool performs these checks more safely because it reports sensitive field names only:

agent-scope-guard --json --fail-on high

Why deleting one Skill may not work

There can be three independent persistence layers:

  • the npm package and its lifecycle scripts
  • the shared physical Skill directory
  • links from individual Agent hosts to that shared directory

A durable fix must reconcile all three and then rerun the audit after the next CLI upgrade.

Fair interpretation

Automatic Skill installation can be a convenience feature. The risk arises when convenience crosses an invisible trust boundary: broad implicit triggers, multiple hosts, ambient secrets, or external writes without explicit confirmation. The safer product design is explicit delegation plus narrow credential and permission scopes.