Local State Management
Relevant source files
The following files were used as context for generating this wiki page:
The ollacc system employs a file-based local state management strategy to persist user configurations, authentication tokens, and model preferences. This state is primarily stored within a hidden directory in the user's home folder, ensuring that the tool remains portable and does not require a heavy database backend. The management of this state involves initial provisioning during installation, secure storage of sensitive credentials, and utility functions for updating or clearing specific state variables.
Local state serves as the bridge between the interactive CLI and the Anthropic SDK, allowing the tool to bypass local Ollama server installations by directly injecting environment variables derived from stored configuration.
Sources: README.md:16-30, install.sh:16-18
Configuration Storage and Structure
The primary repository for local state is the ~/.ollacc/ directory. Within this directory, a config file acts as a flat-file key-value store. This file is managed with strict Unix permissions (chmod 600) to ensure that sensitive data, such as API tokens, is only readable by the owner.
Key Components
| Component | Path | Permissions | Description |
|---|---|---|---|
| Install Directory | ~/.ollacc/ | 700 | Root directory for all local state. |
| Main Config | ~/.ollacc/config | 600 | Shell-compatible script containing variable assignments. |
| Example Config | ~/.ollacc/ollacc.conf.example | 644 | Reference file for manual configuration. |
Sources: install.sh:35-42, install.sh:54-63, README.md:58-62
State Variables
The system persists three primary variables within the config file:
ANTHROPIC_AUTH_TOKEN: The Bearer token used for authenticating with the Ollama Cloud API.ANTHROPIC_BASE_URL: The API endpoint, defaulting tohttps://ollama.com.OLLAMA_CLAUDE_DEFAULT_MODEL: The user's preferred model slug, used to skip the selection menu on subsequent runs.
Sources: lib/auth.sh:8-12, lib/menu.sh:45-58, README.md:92-96
Data Flow and Persistence Logic
The system utilizes a specialized set of Bash functions to perform CRUD (Create, Read, Update, Delete) operations on the configuration file. This logic is designed to be idempotent and safe, preserving user comments while updating specific keys.
Configuration Update Process
The following diagram illustrates how the system updates a configuration value using the config_set function.
The config_set function handles character escaping for characters like \, $, and " to prevent shell injection or parsing errors when the config is later sourced.
Sources: lib/config.sh:38-66
Lifecycle of Local State
Local state moves through several stages from initial installation to potential removal.
Sources: install.sh:54-63, lib/auth.sh:17-51, lib/menu.sh:51-58
State Clearing and Management Flags
The system provides built-in mechanisms to modify or reset the local state without manual file editing. These are handled via specific command-line flags processed before the main application logic.
Management Commands
| Flag | Function Called | Effect |
|---|---|---|
--model-clear | config_unset | Removes OLLAMA_CLAUDE_DEFAULT_MODEL from config. |
--key-clear | config_unset | Removes ANTHROPIC_AUTH_TOKEN from config. |
The config_unset function uses awk to filter out lines matching the specified key while maintaining the rest of the file's integrity and comments.
Sources: lib/flags.sh:11-30, lib/config.sh:70-81
State Uninstallation
The uninstall.sh script manages the teardown of local state. While it always removes the shell aliases, it provides the user with a choice regarding the local configuration directory to prevent accidental data loss.
Sources: uninstall.sh:47-62
Summary of State Usage
Local state is not merely passive storage; it is actively transformed into the environment required by the Anthropic SDK. The function auth_export_sdk_env reads the local state and exports ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN, while explicitly clearing ANTHROPIC_API_KEY to ensure the SDK uses the Bearer token path required by the Ollama Cloud API.
Sources: lib/auth.sh:55-60, README.md:118-125