RFC: Centralized Environment-Based Configuration and Extension Management

[oca-agent]

Background

Currently, the goose-mm-bridge manages user isolation by mapping Mattermost users to Linux accounts. Each user's Goose session relies on a config.yaml located in their home directory (~/.config/goose/config.yaml). This approach has several drawbacks:

1. Security: Sensitive credentials (like API keys) are exposed in plain-text files across multiple user directories.
2. Maintenance: Adding new tools or changing models requires manual updates to every user's configuration.
3. Provisioning Complexity: Setting up a new user requires pre-configuring their home directory.

Proposed Change

Control the entire Goose configuration via environment variables managed centrally by the bridge process.

1. Environment Variable Overrides

Goose supports provider-specific environment variables (e.g., OPENAI_API_KEY, GOOSE_PROVIDER, GOOSE_MODEL). The bridge will be updated to accept these settings in its own .env file and pass them down to the goose acp subprocess.

2. Secure Subprocess Injection

Since sudo typically clears environment variables for security, the bridge will use /usr/bin/env to explicitly inject configuration into the subprocess:

sudo -u <user> /usr/bin/env GOOSE_PROVIDER=... OPENAI_API_KEY=... goose acp

3. Centralized Extension Management

• Built-ins: Use the --with-builtin <name> flag when starting goose acp to enable tools like developer or summarize for all users.
• MCP Servers: Inject custom MCP servers (like the internal Mattermost bridge) dynamically during the session/new JSON-RPC handshake. This allows the bridge to provide global tools to every user without local configuration.

4. Zero-Conf Home Directory

Instead of a config.yaml, Goose will be configured entirely via environment variables. The process will still run with the user's actual HOME directory, ensuring session databases and logs are owned by the user, but secrets never touch the disk. This eliminates the need for manual filesystem setup in user homes while maintaining strict isolation.

Implementation Plan

1. Update src/config.py: Add support for GOOSE_PROVIDER, GOOSE_MODEL, GOOSE_API_KEY, GOOSE_BUILTIN_EXTENSIONS, and GLOBAL_MCP_SERVERS.
2. Refactor src/goose_acp_client.py:
   • Construct a secure environment dictionary from bridge settings.
   • Modify _start to use the /usr/bin/env injection pattern and --with-builtin flags.
   • Update create_session to dynamically merge global MCP servers.
3. Simplify setup_user.sh: Remove config.yaml generation. Focus only on user creation and sudoers entries.
4. Validation: Ensure new users are ready for Goose sessions immediately after OS-level setup without manual configuration.

---

This plan was generated after research into Goose environment behavior and ACP protocol capabilities.

[mrazza]

A few questions:

For (4) we really want all files the goose agent operates on to be owned by the user under which it is started. It seems cleaner to keep this all in the user's home directory. I don't think we care where the database or logs go --- we do care about configuration and secrets like tokens, however.

Where and how will we manage enabled buildin extensions and MCP connections for these agents?

[oca-agent]

Thanks for the feedback! Here is the refined plan addressing your questions:

1. File Ownership and Home Directory

Instead of redirecting HOME to a bridge-managed directory, we will keep the user's actual home directory.

• Session Data & Logs: Goose will continue to store its session database and logs in the user's standard paths (e.g., ~/.local/share/goose/), ensuring they are owned by the Linux user.
• Secrets & Config: By using environment variable injection (e.g., sudo -u <user> /usr/bin/env OPENAI_API_KEY=... goose acp), we eliminate the need for a ~/.config/goose/config.yaml file. This keeps sensitive tokens out of the user's reach (as they are only in the environment of the running process) while allowing the agent to function.

2. Extension Management

We will centralize management within the bridge configuration:

• Built-in Extensions: We'll add a GOOSE_BUILTIN_EXTENSIONS setting to the bridge (e.g., developer,summarize). These will be passed via the --with-builtin flag when starting the goose acp process.
• MCP Servers: We will define a list of global MCP servers in the bridge's config. These will be dynamically injected into the session/new JSON-RPC handshake, similar to how the internal Mattermost bridge is currently handled. This allows for global tool availability without any per-user local configuration.

[mrazza]

Approved. Generate a PR for this.

[oca-agent]

I have successfully implemented the environment-based configuration and centralized extension management as approved. The changes have been submitted as PR #56 (#56) and are ready for review!