Rename server->core (#638)

.vscode/launch.json

@@ -52,11 +52,11 @@
         "run",
         "test",
         "-w",
-        "packages/server",
+        "packages/core",
         "--",
         "--inspect-brk=9229",
         "--no-file-parallelism",
-        "${workspaceFolder}/packages/server/src/tools/read-many-files.test.ts"
+        "${workspaceFolder}/packages/core/src/tools/read-many-files.test.ts"
       ],
       "cwd": "${workspaceFolder}",
       "console": "integratedTerminal",
@@ -92,11 +92,11 @@
         "run",
         "test",
         "-w",
-        "packages/server",
+        "packages/core",
         "--",
         "--inspect-brk=9229",
         "--no-file-parallelism",
-        "${workspaceFolder}/packages/server/src/tools/read-file.test.ts"
+        "${workspaceFolder}/packages/core/src/tools/read-file.test.ts"
       ],
       "cwd": "${workspaceFolder}",
       "console": "integratedTerminal",
@@ -112,11 +112,11 @@
         "run",
         "test",
         "-w",
-        "packages/server",
+        "packages/core",
         "--",
         "--inspect-brk=9229",
         "--no-file-parallelism",
-        "${workspaceFolder}/packages/server/src/core/turn.test.ts"
+        "${workspaceFolder}/packages/core/src/core/turn.test.ts"
       ],
       "cwd": "${workspaceFolder}",
       "console": "integratedTerminal",
@@ -132,11 +132,11 @@
         "run",
         "test",
         "-w",
-        "packages/server",
+        "packages/core",
         "--",
         "--inspect-brk=9229",
         "--no-file-parallelism",
-        "${workspaceFolder}/packages/server/src/utils/fileUtils.test.ts"
+        "${workspaceFolder}/packages/core/src/utils/fileUtils.test.ts"
       ],
       "cwd": "${workspaceFolder}",
       "console": "integratedTerminal",

CONTRIBUTING.md

@@ -95,7 +95,7 @@ To execute the test suite for the project:
 npm run test
 ```
 
-This will run tests located in the `packages/server` and `packages/cli` directories. Ensure tests pass before submitting any changes.
+This will run tests located in the `packages/core` and `packages/cli` directories. Ensure tests pass before submitting any changes.
 
 ### Linting and Preflight Checks
 

Dockerfile

@@ -35,7 +35,7 @@ USER node
 
 # install gemini-cli and clean up
 COPY packages/cli/dist/gemini-code-cli-*.tgz /usr/local/share/npm-global/gemini-code-cli.tgz
-COPY packages/server/dist/gemini-code-server-*.tgz /usr/local/share/npm-global/gemini-code-server.tgz
+COPY packages/core/dist/gemini-code-server-*.tgz /usr/local/share/npm-global/gemini-code-server.tgz
 RUN npm install -g /usr/local/share/npm-global/gemini-code-cli.tgz /usr/local/share/npm-global/gemini-code-server.tgz \
   && npm cache clean --force \
   && rm -f /usr/local/share/npm-global/gemini-code-{cli,server}.tgz

GEMINI.md

@@ -16,7 +16,7 @@ npm run preflight
 
 ## Writing Tests
 
-When writing tests look at existing tests in packages/server and packages/cli to conform with the conventions in those files.
+When writing tests look at existing tests in packages/core and packages/cli to conform with the conventions in those files.
 
 ## Git Repo
 

docs/architecture.md

@@ -14,10 +14,10 @@ The Gemini CLI is primarily composed of two main packages, along with a suite of
       - History management.
       - Display rendering (including Markdown, code highlighting, and tool messages).
       - Theme and UI customization.
-      - Communication with the Server package.
+      - Communication with the Core package.
       - Manages user configuration settings specific to the CLI.
 
-2.  **Server Package (`packages/server`):**
+2.  **Core Package (`packages/core`):**
 
     - **Purpose:** This acts as the backend for the CLI. It receives requests from the CLI, orchestrates interactions with the Gemini API, and manages the execution of available tools.
     - **Key Features:**
@@ -27,28 +27,28 @@ The Gemini CLI is primarily composed of two main packages, along with a suite of
       - State management for conversations or sessions.
       - Manages server-side configuration.
 
-3.  **Tools (`packages/server/src/tools/`):**
+3.  **Tools (`packages/core/src/tools/`):**
     - **Purpose:** These are individual modules that extend the capabilities of the Gemini model, allowing it to interact with the local environment (e.g., file system, shell commands, web fetching).
-    - **Interaction:** The Server package invokes these tools based on requests from the Gemini model. The CLI then displays the results of tool execution.
+    - **Interaction:** The Core package invokes these tools based on requests from the Gemini model. The CLI then displays the results of tool execution.
 
 ## Interaction Flow
 
 A typical interaction with the Gemini CLI follows this general flow:
 
 1.  **User Input:** The user types a prompt or command into the CLI (`packages/cli`).
-2.  **Request to Server:** The CLI package sends the user's input to the Server package (`packages/server`).
-3.  **Server Processes Request:** The Server package:
+2.  **Request to Core:** The CLI package sends the user's input to the Core package (`packages/core`).
+3.  **Core Processes Request:** The Core package:
     - Constructs an appropriate prompt for the Gemini API, possibly including conversation history and available tool definitions.
     - Sends the prompt to the Gemini API.
 4.  **Gemini API Response:** The Gemini API processes the prompt and returns a response. This response might be a direct answer or a request to use one of the available tools.
 5.  **Tool Execution (if applicable):**
-    - If the Gemini API requests a tool, the Server package prepares to execute it.
+    - If the Gemini API requests a tool, the Core package prepares to execute it.
     - **User Confirmation for Potentially Impactful Tools:** If the requested tool can modify the file system (e.g., file edits, writes) or execute shell commands, the CLI (`packages/cli`) displays a confirmation prompt to the user. This prompt details the tool and its arguments, and the user must approve the execution. Read-only operations (e.g., reading files, listing directories) may not always require this explicit confirmation step.
-    - If confirmed (or if confirmation is not required for the specific tool), the Server package identifies and executes the relevant tool (e.g., `read_file`, `execute_bash_command`).
+    - If confirmed (or if confirmation is not required for the specific tool), the Core package identifies and executes the relevant tool (e.g., `read_file`, `execute_bash_command`).
     - The tool performs its action (e.g., reads a file from the disk).
-    - The result of the tool execution is sent back to the Gemini API by the Server.
+    - The result of the tool execution is sent back to the Gemini API by the Core.
     - The Gemini API processes the tool result and generates a final response.
-6.  **Response to CLI:** The Server package sends the final response (or intermediate tool messages) back to the CLI package.
+6.  **Response to CLI:** The Core package sends the final response (or intermediate tool messages) back to the CLI package.
 7.  **Display to User:** The CLI package formats and displays the response to the user in the terminal.
 
 ## Diagram (Conceptual)
@@ -56,20 +56,20 @@ A typical interaction with the Gemini CLI follows this general flow:
 ```mermaid
 graph TD
     User[User via Terminal] -- Input --> CLI[packages/cli]
-    CLI -- Request --> Server[packages/server]
-    Server -- Prompt/Tool Info --> GeminiAPI[Gemini API]
-    GeminiAPI -- Response/Tool Call --> Server
-    Server -- Tool Details --> CLI
-    CLI -- User Confirms --> Server
-    Server -- Execute Tool --> Tools[Tools e.g., read_file, shell]
-    Tools -- Tool Result --> Server
-    Server -- Final Response --> CLI
+    CLI -- Request --> Core[packages/core]
+    Core -- Prompt/Tool Info --> GeminiAPI[Gemini API]
+    GeminiAPI -- Response/Tool Call --> Core
+    Core -- Tool Details --> CLI
+    CLI -- User Confirms --> Core
+    Core -- Execute Tool --> Tools[Tools e.g., read_file, shell]
+    Tools -- Tool Result --> Core
+    Core -- Final Response --> CLI
     CLI -- Output --> User
 ```
 
 ## Key Design Principles
 
-- **Modularity:** Separating the CLI (frontend) from the Server (backend) allows for independent development and potential future extensions (e.g., different frontends for the same server).
+- **Modularity:** Separating the CLI (frontend) from the Core (backend) allows for independent development and potential future extensions (e.g., different frontends for the same server).
 - **Extensibility:** The tool system is designed to be extensible, allowing new capabilities to be added.
 - **User Experience:** The CLI focuses on providing a rich and interactive terminal experience.
 

docs/core/configuration.md

@@ -1,19 +1,19 @@
-# Gemini CLI Server: Configuration
+# Gemini CLI Core: Configuration
 
-Configuration for the Gemini CLI server component (`packages/server`) is critical for its operation, dictating how it connects to the Gemini API, which model it uses, how tools are executed, and more. Many of these settings are shared with or derived from the main CLI configuration when the CLI initializes the server backend.
+Configuration for the Gemini CLI core component (`packages/core`) is critical for its operation, dictating how it connects to the Gemini API, which model it uses, how tools are executed, and more. Many of these settings are shared with or derived from the main CLI configuration when the CLI initializes the core backend.
 
 ## Primary Configuration Sources
 
-The server's configuration is primarily established when the `Config` object (from `packages/server/src/config/config.ts`) is instantiated. The values come from a combination of:
+The core's configuration is primarily established when the `Config` object (from `packages/core/src/config/config.ts`) is instantiated. The values come from a combination of:
 
-1.  **Hardcoded Defaults:** Fallback values defined within the server and CLI packages.
-2.  **Settings Files (`settings.json` via CLI):** Persistent settings that the CLI reads (User settings `~/.gemini/settings.json`, then Workspace settings `.gemini/settings.json`) and then passes relevant parts to the server configuration.
-3.  **Environment Variables (potentially from `.env` files):** System-wide or session-specific variables. The CLI loads `.env` files (checking current directory, then ancestors, then `~/.env`) and these variables influence the server config.
+1.  **Hardcoded Defaults:** Fallback values defined within the core and CLI packages.
+2.  **Settings Files (`settings.json` via CLI):** Persistent settings that the CLI reads (User settings `~/.gemini/settings.json`, then Workspace settings `.gemini/settings.json`) and then passes relevant parts to the core configuration.
+3.  **Environment Variables (potentially from `.env` files):** System-wide or session-specific variables. The CLI loads `.env` files (checking current directory, then ancestors, then `~/.env`) and these variables influence the core config.
 4.  **Command-Line Arguments (passed from CLI):** Settings chosen by the user at launch time, which have the highest precedence for many options.
 
-## Key Configuration Parameters for the Server
+## Key Configuration Parameters for the Core
 
-These are the main pieces of information the server `Config` object holds and uses:
+These are the main pieces of information the core `Config` object holds and uses:
 
 - **`apiKey` (string):**
 
@@ -23,7 +23,7 @@ These are the main pieces of information the server `Config` object holds and us
 - **`model` (string):**
 
   - **Source:** Command-line argument (`--model`), environment variable (`GEMINI_MODEL`), or a default value (e.g., `gemini-2.5-pro-preview-05-06`).
-  - **Purpose:** Specifies which Gemini model the server should use. (For Vertex AI model names and usage, refer to the main README.md).
+  - **Purpose:** Specifies which Gemini model the core should use. (For Vertex AI model names and usage, refer to the main README.md).
 
 - **`sandbox` (boolean | string):**
 
@@ -41,12 +41,12 @@ These are the main pieces of information the server `Config` object holds and us
 - **`debugMode` (boolean):**
 
   - **Source:** Command-line argument (`--debug_mode`) or environment variables (e.g., `DEBUG=true`, `DEBUG_MODE=true`).
-  - **Purpose:** Enables verbose logging within the server and its tools, which is helpful for development and troubleshooting.
+  - **Purpose:** Enables verbose logging within the core and its tools, which is helpful for development and troubleshooting.
 
 - **`question` (string | undefined):**
 
   - **Source:** Command-line argument (`--question`), usually when input is piped to the CLI.
-  - **Purpose:** Allows a direct question to be passed to the server for processing without interactive input.
+  - **Purpose:** Allows a direct question to be passed to the core for processing without interactive input.
 
 - **`fullContext` (boolean):**
 
@@ -65,20 +65,20 @@ These are the main pieces of information the server `Config` object holds and us
     - `env` (object, optional): Environment variables for the server process.
     - `cwd` (string, optional): Working directory for the server.
     - `timeout` (number, optional): Request timeout in milliseconds.
-  - **Behavior:** The server will attempt to connect to each configured MCP server. Tool names from these servers might be prefixed with the server alias to prevent naming collisions. The server may also adapt tool schemas from MCP servers for internal compatibility.
+  - **Behavior:** The core will attempt to connect to each configured MCP server. Tool names from these servers might be prefixed with the server alias to prevent naming collisions. The core may also adapt tool schemas from MCP servers for internal compatibility.
 - `mcpServerCommand` (string | undefined, **deprecated**):
 
   - **Source:** `settings.json` (`mcpServerCommand` key).
   - **Purpose:** Legacy setting for a single MCP server. Superseded by `mcpServers`.
 
-- `userAgent` (string):
+- **`userAgent` (string):**
 
   - **Source:** Automatically generated by the CLI, often including CLI package name, version, and Node.js environment details.
   - **Purpose:** Sent with API requests to help identify the client making requests to the Gemini API.
 
 - **`userMemory` (string):**
 
-  - **Source:** Loaded from the hierarchical `GEMINI.md` files by the CLI (Global, Project Root/Ancestors, Sub-directory) and passed to the server config.
+  - **Source:** Loaded from the hierarchical `GEMINI.md` files by the CLI (Global, Project Root/Ancestors, Sub-directory) and passed to the core config.
   - **Purpose:** Contains the combined instructional context provided to the Gemini model.
   - **Mutability:** This can be updated if the memory is refreshed by the user (e.g., via the `/memory refresh` command in the CLI).
 
@@ -88,7 +88,7 @@ These are the main pieces of information the server `Config` object holds and us
 
 ## Environment File (`.env`) Loading
 
-The CLI configuration logic, which precedes server initialization, includes loading an `.env` file. The search order is:
+The CLI configuration logic, which precedes core initialization, includes loading an `.env` file. The search order is:
 
 1.  `.env` in the current working directory.
 2.  `.env` in parent directories, up to the project root (containing `.git`) or home directory.
@@ -105,6 +105,6 @@ GEMINI_MODEL="gemini-1.5-flash-latest"
 
 ## Tool Registry Initialization
 
-Upon initialization, the server's `Config` object is also used to create and populate a `ToolRegistry`. This registry is then aware of the `targetDir` and `sandbox` settings, which are vital for the correct and secure operation of tools like `ReadFileTool`, `ShellTool`, etc. The `ToolRegistry` is responsible for making tool schemas available to the Gemini model and for executing tool calls.
+Upon initialization, the core's `Config` object is also used to create and populate a `ToolRegistry`. This registry is then aware of the `targetDir` and `sandbox` settings, which are vital for the correct and secure operation of tools like `ReadFileTool`, `ShellTool`, etc. The `ToolRegistry` is responsible for making tool schemas available to the Gemini model and for executing tool calls.
 
-Proper server configuration, derived from these various sources, is essential for the Gemini CLI to function correctly, securely, and according to the user's intent.
+Proper core configuration, derived from these various sources, is essential for the Gemini CLI to function correctly, securely, and according to the user's intent.

docs/core/index.md

@@ -1,10 +1,10 @@
-# Gemini CLI Server
+# Gemini CLI Core
 
-This section delves into the server component of the Gemini CLI (`packages/server`). The server acts as the backend engine, handling communication with the Gemini API, managing tools, and processing requests from the CLI client.
+This section delves into the core component of the Gemini CLI (`packages/core`). The core acts as the backend engine, handling communication with the Gemini API, managing tools, and processing requests from the CLI client.
 
-## Role of the Server
+## Role of the Core
 
-The server package is a crucial part of the Gemini CLI ecosystem. While the CLI (`packages/cli`) provides the user interface, the server is responsible for:
+The core package is a crucial part of the Gemini CLI ecosystem. While the CLI (`packages/cli`) provides the user interface, the core is responsible for:
 
 - **API Interaction:** Securely communicating with the Google Gemini API, sending user prompts, and receiving model responses.
 - **Prompt Engineering:** Constructing effective prompts for the Gemini model, potentially incorporating conversation history, tool definitions, and instructional context from `GEMINI.md` files.
@@ -14,39 +14,39 @@ The server package is a crucial part of the Gemini CLI ecosystem. While the CLI
   - Executing the requested tools with the provided arguments.
   - Returning tool execution results to the Gemini model for further processing.
 - **Session and State Management:** Keeping track of the conversation state, including history and any relevant context required for coherent interactions.
-- **Configuration:** Managing server-specific configurations, such as API key access, model selection, and tool settings.
+- **Configuration:** Managing core-specific configurations, such as API key access, model selection, and tool settings.
 
 ## Key Components and Functionality
 
-While the exact implementation details are within the `packages/server/src/` directory, key conceptual components include:
+While the exact implementation details are within the `packages/core/src/` directory, key conceptual components include:
 
 - **API Client** (`client.ts`): A module responsible for making HTTP requests to the Gemini API, handling authentication, and parsing responses.
 - **Prompt Management** (`prompts.ts`): Logic for creating and formatting the prompts sent to the Gemini model. This includes integrating user queries, historical context, and tool specifications.
 - **Tool Registry and Execution** (`tool-registry.ts`, `tools.ts`, individual tool files like `read-file.ts`, `shell.ts`):
   - A system for discovering, registering, and describing available tools to the Gemini model.
   - Code for executing each tool safely and effectively, often involving interaction with the operating system or external services.
-- **Configuration (`config.ts`):** Handles loading and providing access to server-side configurations, including API keys, model choices, and potentially tool-specific settings.
+- **Configuration (`config.ts`):** Handles loading and providing access to core-side configurations, including API keys, model choices, and potentially tool-specific settings.
 - **Turn Management (`turn.ts`):** Manages the flow of a single conversational turn, from receiving user input to generating a final response, potentially involving multiple tool calls.
 
 ## Interaction with the CLI
 
-The CLI and Server typically communicate over a local interface (e.g., standard input/output, or a local network connection if designed for broader use, though the current structure suggests a tightly coupled Node.js application).
+The CLI and Core typically communicate over a local interface (e.g., standard input/output, or a local network connection if designed for broader use, though the current structure suggests a tightly coupled Node.js application).
 
-1.  The CLI captures user input and forwards it to the Server.
-2.  The Server processes the input, interacts with the Gemini API and tools as needed.
-3.  The Server sends responses (text, tool calls, errors) back to the CLI.
+1.  The CLI captures user input and forwards it to the Core.
+2.  The Core processes the input, interacts with the Gemini API and tools as needed.
+3.  The Core sends responses (text, tool calls, errors) back to the CLI.
 4.  The CLI formats and displays these responses to the user.
 
 ## Security Considerations
 
-The server plays a vital role in security:
+The core plays a vital role in security:
 
 - **API Key Management:** It handles the `GEMINI_API_KEY` and ensures it is used securely when communicating with the Gemini API.
-- **Tool Execution:** When tools interact with the local system (e.g., `execute_bash_command`), the server (and its underlying tool implementations) must do so with appropriate caution, often involving sandboxing mechanisms to prevent unintended side effects.
+- **Tool Execution:** When tools interact with the local system (e.g., `execute_bash_command`), the core (and its underlying tool implementations) must do so with appropriate caution, often involving sandboxing mechanisms to prevent unintended side effects.
 
 ## Navigating this Section
 
-- **[Server Configuration](./configuration.md):** Details on how to configure the server component, including environment variables and specific settings.
-- **[Server Tools API](./tools-api.md):** Information on how tools are defined, registered, and used by the server.
+- **[Core Configuration](./configuration.md):** Details on how to configure the core component, including environment variables and specific settings.
+- **[Core Tools API](./tools-api.md):** Information on how tools are defined, registered, and used by the core.
 
-Understanding the server's role and architecture is key to comprehending the full capabilities and operational flow of the Gemini CLI.
+Understanding the core's role and architecture is key to comprehending the full capabilities and operational flow of the Gemini CLI.

docs/core/tools-api.md

@@ -1,6 +1,6 @@
-# Gemini CLI Server: Tools API
+# Gemini CLI Core: Tools API
 
-The Gemini CLI server (`packages/server`) features a robust system for defining, registering, and executing tools. These tools extend the capabilities of the Gemini model, allowing it to interact with the local environment, fetch web content, and perform various actions beyond simple text generation.
+The Gemini CLI core (`packages/core`) features a robust system for defining, registering, and executing tools. These tools extend the capabilities of the Gemini model, allowing it to interact with the local environment, fetch web content, and perform various actions beyond simple text generation.
 
 ## Core Concepts
 
@@ -26,11 +26,11 @@ The Gemini CLI server (`packages/server`) features a robust system for defining,
     - **Command-based Discovery:** If `toolDiscoveryCommand` is configured in settings, this command is executed. It's expected to output JSON describing custom tools, which are then registered as `DiscoveredTool` instances.
     - **MCP-based Discovery:** If `mcpServerCommand` is configured, the registry can connect to a Model Context Protocol (MCP) server to list and register tools (`DiscoveredMCPTool`).
   - **Providing Schemas:** Exposing the `FunctionDeclaration` schemas of all registered tools to the Gemini model, so it knows what tools are available and how to use them.
-  - **Retrieving Tools:** Allowing the server to get a specific tool by name for execution.
+  - **Retrieving Tools:** Allowing the core to get a specific tool by name for execution.
 
 ## Built-in Tools
 
-The server comes with a suite of pre-defined tools, typically found in `packages/server/src/tools/`. These include:
+The core comes with a suite of pre-defined tools, typically found in `packages/core/src/tools/`. These include:
 
 - **File System Tools:**
   - `LSTool` (`ls.ts`): Lists directory contents.
@@ -50,15 +50,15 @@ Each of these tools extends `BaseTool` and implements the required methods for i
 ## Tool Execution Flow
 
 1.  **Model Request:** The Gemini model, based on the user's prompt and the provided tool schemas, decides to use a tool and returns a `FunctionCall` part in its response, specifying the tool name and arguments.
-2.  **Server Receives Request:** The server parses this `FunctionCall`.
+2.  **Core Receives Request:** The core parses this `FunctionCall`.
 3.  **Tool Retrieval:** It looks up the requested tool in the `ToolRegistry`.
 4.  **Parameter Validation:** The tool's `validateToolParams()` method is called.
 5.  **Confirmation (if needed):**
     - The tool's `shouldConfirmExecute()` method is called.
-    - If it returns details for confirmation, the server communicates this back to the CLI, which prompts the user.
-    - The user's decision (e.g., proceed, cancel) is sent back to the server.
-6.  **Execution:** If validated and confirmed (or if no confirmation is needed), the server calls the tool's `execute()` method with the provided arguments and an `AbortSignal` (for potential cancellation).
-7.  **Result Processing:** The `ToolResult` from `execute()` is received by the server.
+    - If it returns details for confirmation, the core communicates this back to the CLI, which prompts the user.
+    - The user's decision (e.g., proceed, cancel) is sent back to the core.
+6.  **Execution:** If validated and confirmed (or if no confirmation is needed), the core calls the tool's `execute()` method with the provided arguments and an `AbortSignal` (for potential cancellation).
+7.  **Result Processing:** The `ToolResult` from `execute()` is received by the core.
 8.  **Response to Model:** The `llmContent` from the `ToolResult` is packaged as a `FunctionResponse` and sent back to the Gemini model so it can continue generating a user-facing response.
 9.  **Display to User:** The `returnDisplay` from the `ToolResult` is sent to the CLI to show the user what the tool did.
 
@@ -66,8 +66,8 @@ Each of these tools extends `BaseTool` and implements the required methods for i
 
 While direct programmatic registration of new tools by users isn't explicitly detailed as a primary workflow in the provided files for typical end-users, the architecture supports extension through:
 
-- **Command-based Discovery:** Advanced users or project administrators can define a `toolDiscoveryCommand` in `settings.json`. This command, when run by the Gemini CLI server, should output a JSON array of `FunctionDeclaration` objects. The server will then make these available as `DiscoveredTool` instances. The corresponding `toolCallCommand` would then be responsible for actually executing these custom tools.
+- **Command-based Discovery:** Advanced users or project administrators can define a `toolDiscoveryCommand` in `settings.json`. This command, when run by the Gemini CLI core, should output a JSON array of `FunctionDeclaration` objects. The core will then make these available as `DiscoveredTool` instances. The corresponding `toolCallCommand` would then be responsible for actually executing these custom tools.
   \
-- **MCP Server(s):** For more complex scenarios, one or more MCP servers can be set up and configured via the `mcpServers` setting in `settings.json`. The Gemini CLI server can then discover and use tools exposed by these servers. As mentioned, if you have multiple MCP servers, the tool names will be prefixed with the server name from your configuration (e.g., `serverAlias__actualToolName`).
+- **MCP Server(s):** For more complex scenarios, one or more MCP servers can be set up and configured via the `mcpServers` setting in `settings.json`. The Gemini CLI core can then discover and use tools exposed by these servers. As mentioned, if you have multiple MCP servers, the tool names will be prefixed with the server name from your configuration (e.g., `serverAlias__actualToolName`).
 
 This tool system provides a flexible and powerful way to augment the Gemini model\'s capabilities, making the Gemini CLI a versatile assistant for a wide range of tasks.

docs/index.md

@@ -4,7 +4,7 @@ This documentation provides a comprehensive guide to installing, using, and deve
 
 ## Overview
 
-The Gemini CLI is a tool designed to bring the capabilities of Gemini models to your terminal. It consists of a client-side application (`packages/cli`) that communicates with a local server (`packages/server`), which in turn interacts with the Gemini API. The CLI supports a variety of tools for file system operations, code execution, web fetching, and more, enhancing your workflow with AI-powered assistance.
+The Gemini CLI is a tool designed to bring the capabilities of Gemini models to your terminal. It consists of a client-side application (`packages/cli`) that communicates with a local server (`packages/core`), which in turn interacts with the Gemini API. The CLI supports a variety of tools for file system operations, code execution, web fetching, and more, enhancing your workflow with AI-powered assistance.
 
 ## Navigating the Documentation
 

docs/tools/index.md

@@ -6,7 +6,7 @@ The Gemini CLI is equipped with a powerful set of built-in tools that the Gemini
 
 In the context of the Gemini CLI, tools are specific functions or modules that the Gemini model can request to be executed. For example, if you ask Gemini to "Summarize the contents of `my_document.txt`," the model will likely identify the need to read that file and will request the execution of the `read_file` tool.
 
-The server component (`packages/server`) manages these tools, presents their definitions (schemas) to the Gemini model, executes them when requested, and returns the results to the model for further processing into a user-facing response.
+The server component (`packages/core`) manages these tools, presents their definitions (schemas) to the Gemini model, executes them when requested, and returns the results to the model for further processing into a user-facing response.
 
 ## Why are Tools Important?
 

docs/troubleshooting.md

@@ -12,8 +12,8 @@ This guide provides solutions to common issues and debugging tips.
 
   - A: The CLI configuration is typically managed within `packages/cli/src/config/`. Refer to [CLI Configuration](./cli/configuration.md) for more details.
 
-- **Q: Where are the server configuration files stored?**
-  - A: The server configuration is typically managed within `packages/server/src/config/`. Refer to [Server Configuration](./server/configuration.md) for more details.
+- **Q: Where are the core configuration files stored?**
+  - A: The core configuration is typically managed within `packages/core/src/config/`. Refer to [Core Configuration](./core/configuration.md) for more details.
 
 ## Common Error Messages and Solutions
 
@@ -22,7 +22,7 @@ This guide provides solutions to common issues and debugging tips.
   - **Cause:** Another process is already using the port the server is trying to bind to.
   - **Solution:**
     1.  Stop the other process using the port.
-    2.  Configure the server to use a different port (see [`server/configuration.md`](./server/configuration.md)).
+    2.  Configure the server to use a different port (see [`core/configuration.md`](./core/configuration.md)).
 
 - **Error: Command not found (when using the CLI).**
 
@@ -50,7 +50,7 @@ This guide provides solutions to common issues and debugging tips.
   - Use the `--verbose` flag (if available) with CLI commands for more detailed output.
   - Check the CLI logs, often found in a user-specific configuration or cache directory.
 
-- **Server Debugging:**
+- **Core Debugging:**
 
   - Check the server console output for error messages or stack traces.
   - Increase log verbosity if configurable.

eslint.config.js

@@ -31,7 +31,7 @@ export default tseslint.config(
       'node_modules/*',
       'eslint.config.js',
       'packages/cli/dist/**',
-      'packages/server/dist/**',
+      'packages/core/dist/**',
       'eslint-rules/*',
       'bundle/**',
     ],

package-lock.json

@@ -874,8 +874,8 @@
       "resolved": "packages/cli",
       "link": true
     },
-    "node_modules/@gemini-code/server": {
-      "resolved": "packages/server",
+    "node_modules/@gemini-code/core": {
+      "resolved": "packages/core",
       "link": true
     },
     "node_modules/@google/genai": {
@@ -9309,7 +9309,7 @@
       "name": "@gemini-code/cli",
       "version": "0.1.0",
       "dependencies": {
-        "@gemini-code/server": "0.1.0",
+        "@gemini-code/core": "0.1.0",
         "diff": "^7.0.0",
         "dotenv": "^16.4.7",
         "highlight.js": "^11.11.1",
@@ -9399,9 +9399,31 @@
         "url": "https://github.com/chalk/strip-ansi?sponsor=1"
       }
     },
+    "packages/core": {
+      "name": "@gemini-code/core",
+      "version": "0.1.0",
+      "dependencies": {
+        "@google/genai": "^1.0.1",
+        "@modelcontextprotocol/sdk": "^1.11.0",
+        "diff": "^7.0.0",
+        "dotenv": "^16.4.7",
+        "fast-glob": "^3.3.3",
+        "shell-quote": "^1.8.2"
+      },
+      "devDependencies": {
+        "@types/diff": "^7.0.2",
+        "@types/dotenv": "^6.1.1",
+        "typescript": "^5.3.3",
+        "vitest": "^3.1.1"
+      },
+      "engines": {
+        "node": ">=18"
+      }
+    },
     "packages/server": {
       "name": "@gemini-code/server",
       "version": "0.1.0",
+      "extraneous": true,
       "dependencies": {
         "@google/genai": "^1.0.1",
         "@modelcontextprotocol/sdk": "^1.11.0",

package.json

@@ -27,7 +27,7 @@
     "prerelease:dev": "npm run prerelease:version --workspaces && npm run prerelease:deps --workspaces",
     "bundle": "npm run generate && node_modules/.bin/esbuild packages/cli/index.ts --bundle --outfile=bundle/gemini.js --platform=node --format=esm --banner:js=\"import { createRequire } from 'module'; const require = createRequire(import.meta.url); globalThis.__filename = require('url').fileURLToPath(import.meta.url); globalThis.__dirname = require('path').dirname(globalThis.__filename);\" && bash scripts/copy_bundle_assets.sh",
     "build:cli": "npm run build --workspace packages/cli",
-    "build:server": "npm run build --workspace packages/server",
+    "build:server": "npm run build --workspace packages/core",
     "build:packages": "npm run build:server && npm run build:cli",
     "build:docker": "scripts/build_sandbox.sh -s",
     "tag:docker": "docker tag gemini-cli-sandbox ${SANDBOX_IMAGE_REGISTRY:?SANDBOX_IMAGE_REGISTRY not set}/${SANDBOX_IMAGE_NAME:?SANDBOX_IMAGE_NAME not set}:$npm_package_version",

packages/cli/package.json

@@ -19,7 +19,7 @@
     "typecheck": "tsc --noEmit",
     "prerelease:version": "node ../../scripts/bind_package_version.js",
     "prerelease:deps": "node ../../scripts/bind_package_dependencies.js",
-    "prepublishOnly": "npm publish --workspace=@gemini-code/server",
+    "prepublishOnly": "npm publish --workspace=@gemini-code/core",
     "prepack": "npm run build"
   },
   "files": [
@@ -29,7 +29,7 @@
     "sandboxImageUri": "gemini-cli-sandbox"
   },
   "dependencies": {
-    "@gemini-code/server": "0.1.0",
+    "@gemini-code/core": "0.1.0",
     "diff": "^7.0.0",
     "dotenv": "^16.4.7",
     "highlight.js": "^11.11.1",

packages/cli/src/config/config.test.ts

@@ -10,7 +10,7 @@ import { describe, it, expect, vi, beforeEach, afterEach } from 'vitest';
 import * as os from 'os';
 import { loadCliConfig } from './config.js';
 import { Settings } from './settings.js';
-import * as ServerConfig from '@gemini-code/server';
+import * as ServerConfig from '@gemini-code/core';
 
 const MOCK_HOME_DIR = '/mock/home/user';
 
@@ -28,10 +28,9 @@ vi.mock('read-package-up', () => ({
   ),
 }));
 
-vi.mock('@gemini-code/server', async () => {
-  const actualServer = await vi.importActual<typeof ServerConfig>(
-    '@gemini-code/server',
-  );
+vi.mock('@gemini-code/core', async () => {
+  const actualServer =
+    await vi.importActual<typeof ServerConfig>('@gemini-code/core');
   return {
     ...actualServer,
     loadEnvironment: vi.fn(),

packages/cli/src/config/config.ts

@@ -13,7 +13,7 @@ import {
   createServerConfig,
   loadServerHierarchicalMemory,
   ConfigParameters,
-} from '@gemini-code/server';
+} from '@gemini-code/core';
 import { Settings } from './settings.js';
 import { readPackageUp } from 'read-package-up';
 

packages/cli/src/config/settings.ts

@@ -7,7 +7,7 @@
 import * as fs from 'fs';
 import * as path from 'path';
 import { homedir } from 'os';
-import { MCPServerConfig } from '@gemini-code/server/src/config/config.js';
+import { MCPServerConfig } from '@gemini-code/core/src/config/config.js';
 import stripJsonComments from 'strip-json-comments';
 
 export const SETTINGS_DIRECTORY_NAME = '.gemini';

packages/cli/src/gemini.tsx

@@ -9,7 +9,7 @@ import { render } from 'ink';
 import { App } from './ui/App.js';
 import { loadCliConfig } from './config/config.js';
 import { readStdin } from './utils/readStdin.js';
-import { GeminiClient } from '@gemini-code/server';
+import { GeminiClient } from '@gemini-code/core';
 import { readPackageUp } from 'read-package-up';
 import { fileURLToPath } from 'node:url';
 import { dirname } from 'node:path';

packages/cli/src/ui/App.tsx

@@ -39,7 +39,7 @@ import { DetailedMessagesDisplay } from './components/DetailedMessagesDisplay.js
 import { HistoryItemDisplay } from './components/HistoryItemDisplay.js';
 import { useHistory } from './hooks/useHistoryManager.js';
 import process from 'node:process';
-import { getErrorMessage, type Config } from '@gemini-code/server';
+import { getErrorMessage, type Config } from '@gemini-code/core';
 import { useLogger } from './hooks/useLogger.js';
 import { StreamingContext } from './contexts/StreamingContext.js';
 import { useGitBranchName } from './hooks/useGitBranchName.js';

packages/cli/src/ui/components/Footer.tsx

@@ -7,7 +7,7 @@
 import React from 'react';
 import { Box, Text } from 'ink';
 import { Colors } from '../colors.js';
-import { shortenPath, tildeifyPath } from '@gemini-code/server';
+import { shortenPath, tildeifyPath } from '@gemini-code/core';
 import { ConsoleSummaryDisplay } from './ConsoleSummaryDisplay.js';
 import process from 'node:process';
 import { MemoryUsageDisplay } from './MemoryUsageDisplay.js';

packages/cli/src/ui/components/InputPrompt.tsx

@@ -17,7 +17,7 @@ import process from 'node:process';
 import { useCompletion } from '../hooks/useCompletion.js';
 import { isAtCommand, isSlashCommand } from '../utils/commandUtils.js';
 import { SlashCommand } from '../hooks/slashCommandProcessor.js';
-import { Config } from '@gemini-code/server';
+import { Config } from '@gemini-code/core';
 
 interface InputPromptProps {
   onSubmit: (value: string) => void;

packages/cli/src/ui/components/Tips.tsx

@@ -7,7 +7,7 @@
 import React from 'react';
 import { Box, Text } from 'ink';
 import { Colors } from '../colors.js';
-import { type Config } from '@gemini-code/server';
+import { type Config } from '@gemini-code/core';
 
 interface TipsProps {
   config: Config;

packages/cli/src/ui/components/messages/ToolConfirmationMessage.tsx

@@ -13,7 +13,7 @@ import {
   ToolConfirmationOutcome,
   ToolExecuteConfirmationDetails,
   ToolMcpConfirmationDetails,
-} from '@gemini-code/server';
+} from '@gemini-code/core';
 import {
   RadioButtonSelect,
   RadioSelectItem,

packages/cli/src/ui/hooks/atCommandProcessor.test.ts

@@ -6,7 +6,7 @@
 
 import { describe, it, expect, vi, beforeEach, afterEach, Mock } from 'vitest';
 import { handleAtCommand } from './atCommandProcessor.js';
-import { Config } from '@gemini-code/server';
+import { Config } from '@gemini-code/core';
 import { ToolCallStatus } from '../types.js';
 import { UseHistoryManagerReturn } from './useHistoryManager.js';
 import * as fsPromises from 'fs/promises';

packages/cli/src/ui/hooks/atCommandProcessor.ts

@@ -12,7 +12,7 @@ import {
   getErrorMessage,
   isNodeError,
   unescapePath,
-} from '@gemini-code/server';
+} from '@gemini-code/core';
 import {
   HistoryItem,
   IndividualToolCallDisplay,

packages/cli/src/ui/hooks/shellCommandProcessor.test.ts

@@ -7,7 +7,7 @@
 /* eslint-disable @typescript-eslint/no-explicit-any */
 import { act, renderHook } from '@testing-library/react';
 import { useShellCommandProcessor } from './shellCommandProcessor.js';
-import { type Config } from '@gemini-code/server';
+import { type Config } from '@gemini-code/core';
 import { type PartListUnion } from '@google/genai';
 import { existsSync, readFileSync, unlinkSync } from 'fs';
 import type * as FsMod from 'fs';

packages/cli/src/ui/hooks/shellCommandProcessor.ts

@@ -8,7 +8,7 @@ import { spawn } from 'child_process';
 import type { HistoryItemWithoutId } from '../types.js';
 import type { exec as ExecType } from 'child_process';
 import { useCallback } from 'react';
-import { Config } from '@gemini-code/server';
+import { Config } from '@gemini-code/core';
 import { type PartListUnion } from '@google/genai';
 import { UseHistoryManagerReturn } from './useHistoryManager.js';
 import crypto from 'crypto';

packages/cli/src/ui/hooks/slashCommandProcessor.test.ts

@@ -56,7 +56,7 @@ import {
   type SlashCommandActionReturn,
 } from './slashCommandProcessor.js';
 import { MessageType } from '../types.js';
-import { type Config } from '@gemini-code/server';
+import { type Config } from '@gemini-code/core';
 
 import * as ShowMemoryCommandModule from './useShowMemoryCommand.js';
 import { GIT_COMMIT_INFO } from '../../generated/git-commit.js';

packages/cli/src/ui/hooks/slashCommandProcessor.ts

@@ -9,7 +9,7 @@ import { type PartListUnion } from '@google/genai';
 import open from 'open';
 import process from 'node:process';
 import { UseHistoryManagerReturn } from './useHistoryManager.js';
-import { Config } from '@gemini-code/server';
+import { Config } from '@gemini-code/core';
 import { Message, MessageType, HistoryItemWithoutId } from '../types.js';
 import { createShowMemoryAction } from './useShowMemoryCommand.js';
 import { GIT_COMMIT_INFO } from '../../generated/git-commit.js';

packages/cli/src/ui/hooks/useAutoAcceptIndicator.test.ts

@@ -16,14 +16,14 @@ import {
 import { renderHook, act } from '@testing-library/react';
 import { useAutoAcceptIndicator } from './useAutoAcceptIndicator.js';
 
-import type { Config as ActualConfigType } from '@gemini-code/server';
+import type { Config as ActualConfigType } from '@gemini-code/core';
 import { useInput, type Key as InkKey } from 'ink';
 
 vi.mock('ink');
 
-vi.mock('@gemini-code/server', async () => {
+vi.mock('@gemini-code/core', async () => {
   const actualServerModule = (await vi.importActual(
-    '@gemini-code/server',
+    '@gemini-code/core',
   )) as Record<string, unknown>;
   return {
     ...actualServerModule,
@@ -31,7 +31,7 @@ vi.mock('@gemini-code/server', async () => {
   };
 });
 
-import { Config } from '@gemini-code/server';
+import { Config } from '@gemini-code/core';
 
 interface MockConfigInstanceShape {
   getAlwaysSkipModificationConfirmation: Mock<() => boolean>;

packages/cli/src/ui/hooks/useAutoAcceptIndicator.ts

@@ -6,7 +6,7 @@
 
 import { useState, useEffect } from 'react';
 import { useInput } from 'ink';
-import type { Config } from '@gemini-code/server';
+import type { Config } from '@gemini-code/core';
 
 export interface UseAutoAcceptIndicatorArgs {
   config: Config;

packages/cli/src/ui/hooks/useCompletion.ts

@@ -12,7 +12,7 @@ import {
   escapePath,
   unescapePath,
   getErrorMessage,
-} from '@gemini-code/server';
+} from '@gemini-code/core';
 import {
   MAX_SUGGESTIONS_TO_SHOW,
   Suggestion,

packages/cli/src/ui/hooks/useGeminiStream.ts

@@ -22,7 +22,7 @@ import {
   ToolExecuteConfirmationDetails,
   ToolResultDisplay,
   ToolCallRequestInfo,
-} from '@gemini-code/server';
+} from '@gemini-code/core';
 import { type PartListUnion, type Part } from '@google/genai';
 import {
   StreamingState,
@@ -39,7 +39,7 @@ import { useStateAndRef } from './useStateAndRef.js';
 import { UseHistoryManagerReturn } from './useHistoryManager.js';
 import { useLogger } from './useLogger.js';
 import { useToolScheduler, mapToDisplay } from './useToolScheduler.js';
-import { GeminiChat } from '@gemini-code/server/src/core/geminiChat.js';
+import { GeminiChat } from '@gemini-code/core/src/core/geminiChat.js';
 
 export function mergePartListUnions(list: PartListUnion[]): PartListUnion {
   const resultParts: PartListUnion = [];

packages/cli/src/ui/hooks/useLogger.ts

@@ -5,7 +5,7 @@
  */
 
 import { useState, useEffect } from 'react';
-import { Logger } from '@gemini-code/server';
+import { Logger } from '@gemini-code/core';
 
 /**
  * Hook to manage the logger instance.

packages/cli/src/ui/hooks/useShowMemoryCommand.ts

@@ -5,7 +5,7 @@
  */
 
 import { Message, MessageType } from '../types.js';
-import { Config } from '@gemini-code/server';
+import { Config } from '@gemini-code/core';
 
 export function createShowMemoryAction(
   config: Config | null,

packages/cli/src/ui/hooks/useToolScheduler.ts

@@ -12,7 +12,7 @@ import {
   Tool,
   ToolCallConfirmationDetails,
   ToolResult,
-} from '@gemini-code/server';
+} from '@gemini-code/core';
 import { Part, PartUnion, PartListUnion } from '@google/genai';
 import { useCallback, useEffect, useState } from 'react';
 import {

packages/cli/src/ui/types.ts

@@ -7,7 +7,7 @@
 import {
   ToolCallConfirmationDetails,
   ToolResultDisplay,
-} from '@gemini-code/server';
+} from '@gemini-code/core';
 
 // Only defining the state enum needed by the UI
 export enum StreamingState {

packages/cli/src/utils/startupWarnings.ts

@@ -7,7 +7,7 @@
 import fs from 'fs/promises';
 import os from 'os';
 import { join as pathJoin } from 'node:path';
-import { getErrorMessage } from '@gemini-code/server';
+import { getErrorMessage } from '@gemini-code/core';
 
 const warningsFilePath = pathJoin(os.tmpdir(), 'gemini-code-cli-warnings.txt');
 

packages/cli/tsconfig.json

@@ -8,5 +8,5 @@
   },
   "include": ["index.ts", "src/**/*.ts", "src/**/*.tsx", "src/**/*.json"],
   "exclude": ["node_modules", "dist"],
-  "references": [{ "path": "../server" }]
+  "references": [{ "path": "../core" }]
 }

packages/core/package.json

@@ -1,5 +1,5 @@
 {
-  "name": "@gemini-code/server",
+  "name": "@gemini-code/core",
   "version": "0.1.0",
   "description": "Gemini CLI Server",
   "type": "module",