[Bug]: The command tool cannot properly handle channel configuration

[hightman]

OpenACP Version

2026.402.5

Messaging Platform

Telegram

AI Agent

opencode

Bug Description

After a normal installation, I can’t reconfigure the channels, whether I use openacp config or openacp onboard.

Steps to Reproduce

1. openacp config
2. select 'Channels'

Expected Behavior

Modify the configuration normally.

Logs / Error Output

All channel configuration information is lost and shows “Not configured.”

Configuration

Operating System

Ubuntu 22.04

Node.js Version

v24

Additional Context

If I use openacp onboard, all channels are shown as disabled.

[0xmrpeter]

Fixed in commit 8b9b7ff on the develop branch.

Root Causes

After the plugin system migration, channel configuration (botToken, chatId, etc.) is stored in ~/.openacp/plugins/data/@openacp/telegram/settings.json via SettingsManager — but several code paths still read from the old config.channels field in config.json, which is empty after a fresh setup.

Three separate issues were found:

1. Wrong SettingsManager base path in openacp config
cmdConfig created new SettingsManager(path.join(root, 'plugins')) — missing the data subdirectory. It was reading from ~/.openacp/plugins/ instead of ~/.openacp/plugins/data/, so all settings came back empty and channels showed "Not configured".

2. Status display functions read from config.channels only

• getChannelStatuses() in setup-channels.ts (used by openacp onboard)
• editChannels() in config-editor.ts (used by openacp config)
• summarizeConfig() in helpers.ts (the "Current configuration" note in openacp onboard)
• telegramCheck in openacp doctor

All of these checked config.channels[id] to determine configured/enabled status, ignoring plugin settings entirely.

3. runReconfigure() never received settingsManager
cmdOnboard created a SettingsManager instance but never passed it to runReconfigure(), so the reconfigure wizard had no way to read plugin settings.

Fix Summary

• getChannelStatuses(): made async, now checks SettingsManager first, falls back to config.channels for legacy configs
• configureChannels(), noteChannelStatus(): propagate settingsManager param
• editChannels(): check SettingsManager for display status
• editDiscord(): fix basePath (plugins → plugins/data)
• summarizeConfig(): made async, check SettingsManager for channel status
• telegramCheck: read botToken/chatId from plugin settings first
• cmdConfig: fix SettingsManager basePath (plugins → plugins/data)
• cmdOnboard / runReconfigure(): pass settingsManager through the call chain

Tests added for getChannelStatuses, summarizeConfig, and telegramCheck covering plugin-settings-first read behavior.