@codeflyai/codefly 0.24.1 → 0.24.2

package/bundle/policies/plan.toml

@@ -0,0 +1,70 @@
+# Priority system for policy rules:
+# - Higher priority numbers win over lower priority numbers
+# - When multiple rules match, the highest priority rule is applied
+# - Rules are evaluated in order of priority (highest first)
+#
+# Priority bands (tiers):
+# - Default policies (TOML): 1 + priority/1000 (e.g., priority 100 → 1.100)
+# - User policies (TOML): 2 + priority/1000 (e.g., priority 100 → 2.100)
+# - Admin policies (TOML): 3 + priority/1000 (e.g., priority 100 → 3.100)
+#
+# This ensures Admin > User > Default hierarchy is always preserved,
+# while allowing user-specified priorities to work within each tier.
+#
+# Settings-based and dynamic rules (all in user tier 2.x):
+#   2.95: Tools that the user has selected as "Always Allow" in the interactive UI
+#   2.9:  MCP servers excluded list (security: persistent server blocks)
+#   2.4:  Command line flag --exclude-tools (explicit temporary blocks)
+#   2.3:  Command line flag --allowed-tools (explicit temporary allows)
+#   2.2:  MCP servers with trust=true (persistent trusted servers)
+#   2.1:  MCP servers allowed list (persistent general server allows)
+#
+# TOML policy priorities (before transformation):
+#   10: Write tools default to ASK_USER (becomes 1.010 in default tier)
+#   20: Plan mode catch-all DENY override (becomes 1.020 in default tier)
+#   50: Read-only tools (becomes 1.050 in default tier)
+#   999: YOLO mode allow-all (becomes 1.999 in default tier)
+
+# Catch-All: Deny everything by default in Plan mode.
+
+[[rule]]
+decision = "deny"
+priority = 20
+modes = ["plan"]
+
+# Explicitly Allow Read-Only Tools in Plan mode.
+
+[[rule]]
+toolName = "glob"
+decision = "allow"
+priority = 50
+modes = ["plan"]
+
+[[rule]]
+toolName = "search_file_content"
+decision = "allow"
+priority = 50
+modes = ["plan"]
+
+[[rule]]
+toolName = "list_directory"
+decision = "allow"
+priority = 50
+modes = ["plan"]
+
+[[rule]]
+toolName = "read_file"
+decision = "allow"
+priority = 50
+modes = ["plan"]
+
+[[rule]]
+toolName = "google_web_search"
+decision = "allow"
+priority = 50
+modes = ["plan"]
+
+[[rule]]
+toolName = "SubagentInvocation"
+decision = "allow"
+priority = 50

package/bundle/policies/read-only.toml

@@ -45,11 +45,6 @@ toolName = "read_file"
 decision = "allow"
 priority = 50
 
-[[rule]]
-toolName = "read_many_files"
-decision = "allow"
-priority = 50
-
 [[rule]]
 toolName = "google_web_search"
 decision = "allow"

package/bundle/policies/yolo.toml

@@ -29,3 +29,4 @@
 decision = "allow"
 priority = 999
 modes = ["yolo"]
+allow_redirection = true

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@codeflyai/codefly",
-  "version": "0.24.1",
+  "version": "0.24.2",
   "engines": {
     "node": ">=20.0.0"
   },
@@ -40,6 +40,8 @@
     "test": "npm run test --workspaces --if-present",
     "test:ci": "npm run test:ci --workspaces --if-present && npm run test:scripts",
     "test:scripts": "vitest run --config ./scripts/tests/vitest.config.ts",
+    "test:always_passing_evals": "vitest run --config evals/vitest.config.ts",
+    "test:all_evals": "cross-env RUN_EVALS=1 vitest run --config evals/vitest.config.ts",
     "test:e2e": "cross-env VERBOSE=true KEEP_OUTPUT=true npm run test:integration:sandbox:none",
     "test:integration:all": "npm run test:integration:sandbox:none && npm run test:integration:sandbox:docker && npm run test:integration:sandbox:podman",
     "test:integration:sandbox:none": "cross-env CODEFLY_SANDBOX=false vitest run --root ./integration-tests",
@@ -51,8 +53,8 @@
     "lint:all": "node scripts/lint.js",
     "format": "prettier --experimental-cli --write .",
     "typecheck": "npm run typecheck --workspaces --if-present",
-    "preflight": "npm run clean && npm ci && npm run format && npm run lint:ci && npm run build && npm run typecheck && npm run test:ci",
-    "prepare": "husky && npm run bundle",
+    "preflight": "npm run clean && npm ci && npm run format && npm run build && npm run lint:ci && npm run typecheck && npm run test:ci",
+    "prepare": "husky",
     "prepare:package": "node scripts/prepare-package.js",
     "release:version": "node scripts/version.js",
     "telemetry": "node scripts/telemetry.js",
@@ -61,7 +63,7 @@
     "pre-commit": "node scripts/pre-commit.js"
   },
   "overrides": {
-    "ink": "npm:@jrichman/ink@6.4.6",
+    "ink": "npm:@jrichman/ink@6.4.7",
     "wrap-ansi": "9.0.2",
     "cliui": {
       "wrap-ansi": "7.0.0"
@@ -76,6 +78,7 @@
     "LICENSE"
   ],
   "devDependencies": {
+    "@agentclientprotocol/sdk": "^0.12.0",
     "@octokit/rest": "^22.0.0",
     "@types/marked": "^5.0.2",
     "@types/mime-types": "^3.0.1",
@@ -120,7 +123,8 @@
     "yargs": "^17.7.2"
   },
   "dependencies": {
-    "ink": "npm:@jrichman/ink@6.4.6",
+    "clipboardy": "^5.0.2",
+    "ink": "npm:@jrichman/ink@6.4.7",
     "latest-version": "^9.0.0",
     "mysql2": "^3.16.0",
     "pg": "^8.16.3",
@@ -133,6 +137,7 @@
     "@lydell/node-pty-linux-x64": "1.1.0",
     "@lydell/node-pty-win32-arm64": "1.1.0",
     "@lydell/node-pty-win32-x64": "1.1.0",
+    "keytar": "^7.9.0",
     "node-pty": "^1.0.0"
   },
   "lint-staged": {

package/bundle/docs/get-started/deployment.md

@@ -1,143 +0,0 @@
-Note: This page will be replaced by [installation.md](installation.md).
-
-# Gemini CLI installation, execution, and deployment
-
-Install and run Gemini CLI. This document provides an overview of Gemini CLI's
-installation methods and deployment architecture.
-
-## How to install and/or run Gemini CLI
-
-There are several ways to run Gemini CLI. The recommended option depends on how
-you intend to use Gemini CLI.
-
-- As a standard installation. This is the most straightforward method of using
-  Gemini CLI.
-- In a sandbox. This method offers increased security and isolation.
-- From the source. This is recommended for contributors to the project.
-
-### 1. Standard installation (recommended for standard users)
-
-This is the recommended way for end-users to install Gemini CLI. It involves
-downloading the Gemini CLI package from the NPM registry.
-
-- **Global install:**
-
-  ```bash
-  npm install -g @google/gemini-cli
-  ```
-
-  Then, run the CLI from anywhere:
-
-  ```bash
-  gemini
-  ```
-
-- **NPX execution:**
-
-  ```bash
-  # Execute the latest version from NPM without a global install
-  npx @google/gemini-cli
-  ```
-
-### 2. Run in a sandbox (Docker/Podman)
-
-For security and isolation, Gemini CLI can be run inside a container. This is
-the default way that the CLI executes tools that might have side effects.
-
-- **Directly from the registry:** You can run the published sandbox image
-  directly. This is useful for environments where you only have Docker and want
-  to run the CLI.
-  ```bash
-  # Run the published sandbox image
-  docker run --rm -it us-docker.pkg.dev/gemini-code-dev/gemini-cli/sandbox:0.1.1
-  ```
-- **Using the `--sandbox` flag:** If you have Gemini CLI installed locally
-  (using the standard installation described above), you can instruct it to run
-  inside the sandbox container.
-  ```bash
-  gemini --sandbox -y -p "your prompt here"
-  ```
-
-### 3. Run from source (recommended for Gemini CLI contributors)
-
-Contributors to the project will want to run the CLI directly from the source
-code.
-
-- **Development mode:** This method provides hot-reloading and is useful for
-  active development.
-  ```bash
-  # From the root of the repository
-  npm run start
-  ```
-- **Production-like mode (Linked package):** This method simulates a global
-  installation by linking your local package. It's useful for testing a local
-  build in a production workflow.
-
-  ```bash
-  # Link the local cli package to your global node_modules
-  npm link packages/cli
-
-  # Now you can run your local version using the `gemini` command
-  gemini
-  ```
-
----
-
-### 4. Running the latest Gemini CLI commit from GitHub
-
-You can run the most recently committed version of Gemini CLI directly from the
-GitHub repository. This is useful for testing features still in development.
-
-```bash
-# Execute the CLI directly from the main branch on GitHub
-npx https://github.com/google-gemini/gemini-cli
-```
-
-## Deployment architecture
-
-The execution methods described above are made possible by the following
-architectural components and processes:
-
-**NPM packages**
-
-Gemini CLI project is a monorepo that publishes two core packages to the NPM
-registry:
-
-- `@google/gemini-cli-core`: The backend, handling logic and tool execution.
-- `@google/gemini-cli`: The user-facing frontend.
-
-These packages are used when performing the standard installation and when
-running Gemini CLI from the source.
-
-**Build and packaging processes**
-
-There are two distinct build processes used, depending on the distribution
-channel:
-
-- **NPM publication:** For publishing to the NPM registry, the TypeScript source
-  code in `@google/gemini-cli-core` and `@google/gemini-cli` is transpiled into
-  standard JavaScript using the TypeScript Compiler (`tsc`). The resulting
-  `dist/` directory is what gets published in the NPM package. This is a
-  standard approach for TypeScript libraries.
-
-- **GitHub `npx` execution:** When running the latest version of Gemini CLI
-  directly from GitHub, a different process is triggered by the `prepare` script
-  in `package.json`. This script uses `esbuild` to bundle the entire application
-  and its dependencies into a single, self-contained JavaScript file. This
-  bundle is created on-the-fly on the user's machine and is not checked into the
-  repository.
-
-**Docker sandbox image**
-
-The Docker-based execution method is supported by the `gemini-cli-sandbox`
-container image. This image is published to a container registry and contains a
-pre-installed, global version of Gemini CLI.
-
-## Release process
-
-The release process is automated through GitHub Actions. The release workflow
-performs the following actions:
-
-1.  Build the NPM packages using `tsc`.
-2.  Publish the NPM packages to the artifact registry.
-3.  Create GitHub releases with bundled assets.