[Bug]: Connector ingest tools are exposed to code-mode agents (should be gated by run mode)

[ppsplus-bradh]

Description

code-mode runs (codebase documentation, outputMode: "repository") are handed the full set of external connector ingest tools — openwiki_ingest_connector (enum includes google, slack, x, notion, hackernews, web-search, git-repo), openwiki_ingest_all_connectors, and the MCP connector tools. A codebase-documentation agent reads a git repo and writes openwiki/*.md; it has no business ingesting Gmail/Slack/X and should never be offered those tools.

The toolset is built unconditionally: src/agent/index.ts:250 calls tools: createOpenWikiConnectorTools() with no dependence on the run mode/command, and createOpenWikiConnectorTools() (src/connectors/tools.ts:23) takes no mode argument. So personal (local-wiki) and code (repository) runs get an identical toolset.

The practical failure: under a large/--recursive codebase run the subagent machinery fans out, and a subagent can call openwiki_ingest_connector({connectorId:"google"}). With no connector credentials configured (a normal state for a pure codebase-doc run, e.g. CI), that path throws Gmail refresh token is required for OAuth refresh. (src/auth/tokens.ts:66-68, reached because isGmailEnabled defaults to enabled at src/connectors/sources/gmail.ts:331). Combined with the uncaught-tool-error behavior tracked in #426/#427, a single unwanted connector call terminates the entire run — after it may have executed for a long time and produced zero output.

This issue is specifically about mode-gating the toolset (the tools shouldn't be present in code mode at all). It is complementary to, not a duplicate of:

• Connector tools throw instead of returning errors as tool results, so the model can't self-correct (e.g. wrong MCP tool name) #427 — connector tools throw instead of returning errors as tool results (defense in depth: even a legitimately-offered connector tool should return, not throw).
• Any tool error crashes the whole run via unhandled promise rejection in langchain tool-call transformer #426 — any tool error becomes an unhandled rejection that crashes the process (the systemic backstop).

Gating (this issue) removes the tools from the mode where they make no sense; #427/#426 make whatever remains survivable. All three are worth fixing.

Steps to Reproduce

1. Build from source.
2. Run a code-mode codebase-documentation run (repository output mode) with no connector credentials configured, ideally --recursive over a large tree so subagents fan out.
3. If any (sub)agent calls openwiki_ingest_connector({connectorId:"google"}) (or openwiki_ingest_all_connectors), the connector path is entered even though this is a codebase-doc run.

Expected Behavior

code-mode (codebase documentation, outputMode: "repository") runs should not be offered external connector-ingest tools at all. Connector ingestion belongs to the personal/connector workflow (local-wiki).

Actual Behavior

code-mode agents receive the full connector-ingest toolset (openwiki_ingest_connector, openwiki_ingest_all_connectors, MCP connector tools). A subagent can invoke Gmail/Slack/X ingestion during what should be a pure git-repo → markdown run; with no credentials this throws and (via #426) can crash the whole run.

Environment

• OS: Linux (ubuntu-latest CI); reproducible cross-platform
• Node.js version: 22.x
• OpenWiki version: 0.2.x (main); createOpenWikiConnectorTools call site unchanged across 0.1.x–0.2.x

Additional Context

Relevant source (main):

• src/agent/index.ts:250 — tools: createOpenWikiConnectorTools() (unconditional; outputMode is already in scope at runOpenWikiAgentCore line ~213 and is the natural gating axis — "repository" = code mode).
• src/connectors/tools.ts:23 — createOpenWikiConnectorTools() takes no mode arg; openwiki_ingest_connector enum at lines 96–104.
• src/connectors/tools.ts:241-248 — ingestConnector calls registry[connectorId].ingest(options) with no try/catch. Note ingestAllConnectors (lines 270–281) is also an unguarded loop — neither single- nor all-connector ingest isolates a per-connector failure (relevant to Connector tools throw instead of returning errors as tool results, so the model can't self-correct (e.g. wrong MCP tool name) #427).
• src/connectors/sources/gmail.ts:122 → getOAuthAccessToken("gmail"); :331 isGmailEnabled defaults to enabled.
• src/auth/tokens.ts:66-68 — throws when refresh token is absent.

Suggested fix: pass the run mode/outputMode into createOpenWikiConnectorTools() (or filter at the createDeepAgent call site) so repository/code runs get no connector-ingest tools. A per-mode allowlist would also cover the MCP connector tools.

[ppsplus-bradh]

Opened #449 to address this.

Note on approach — it diverges from this issue's title. I started with the suggested "gate connector tools out of code mode," but a blanket mode-gate over-removes git-repo, which openwiki/integrations/connectors.md documents as legitimately relevant to code mode ("documenting a different target repo than the one being ingested from"). Deciding code mode should have no connectors would contradict documented behavior.

So #449 takes a more robust, less presumptuous route:

1. Resilience — every connector tool's func is wrapped so a throw becomes a structured, model-visible result instead of an uncaught crash (abort / LangGraph graph-interrupt signals are re-thrown, never swallowed). This fixes the crash for all run modes, not just code.
2. Operator control — an allow/deny tool filter via --allow-tools/--deny-tools and OPENWIKI_ALLOW_TOOLS/OPENWIKI_DENY_TOOLS (wired through both the run and scheduled ingest/cron paths). Default = all tools, so no behavior change; an operator who does want code-mode CI to exclude connectors can set e.g. OPENWIKI_DENY_TOOLS=openwiki_ingest_connector,openwiki_ingest_all_connectors.
3. Prompt gating — the connector-ingestion discipline block is only emitted when connector tools are actually present, so the agent isn't told to call tools it doesn't have.

This is complementary to #426 / #427 (the general unhandled-rejection / return-don't-throw layer); #449 adds the connector-specific graceful-failure wrapper plus operator-facing control and prompt consistency.