Per-user CODE_API_KEY UI is stale after bash_tool decoupling

[danny-avila]

Context

Follow-up from PR #12712 (Phase 4 of Agent Skills umbrella #12625). That PR decoupled bash_tool registration and skill-file priming from per-user CODE_API_KEY lookups — the sandbox API key now resolves from process.env.LIBRECHAT_CODE_API_KEY only, gated on the execute_code capability.

The frontend still has a per-user credential flow at client/src/hooks/Plugins/useAuthCodeTool.ts that installs LIBRECHAT_CODE_API_KEY via updateUserPlugins under pluginKey: Tools.execute_code. Those values are stored via getUserPluginAuthValue and read by loadAuthValues.

After #12712, the per-user value is no longer read by the skills / bash-tool runtime. It's still consulted by the legacy CodeExecutionTool path, PTC (classification.ts), post-execution file-download callbacks, and sandbox file-upload routes. So the UI isn't entirely dead code, but its meaning is now inconsistent: entering a key there does nothing for agent-skills usage, while the system-level env var governs sandbox access for bash_tool / skill files.

Risk

Users who configure a key via the UI will reasonably expect it to enable code execution for skills and get silent no-ops instead. Likely to generate "why doesn't my key work?" support traffic.

Options

A — Remove the UI entirely. Simplest. Drop useAuthCodeTool.ts and any consumers. Admins set LIBRECHAT_CODE_API_KEY at the server level; per-user keys aren't supported anywhere. Non-skills paths (legacy CodeExecutionTool, PTC, file callbacks) would also stop accepting per-user keys — needs a sweep to confirm no one relies on it.

B — Rewire all remaining CODE_API_KEY consumers to env-only. Finish the job #12712 started: strip loadAuthValues({ authFields: [EnvVar.CODE_API_KEY] }) from handleTools.js, callbacks.js, classification.ts, files.js, process.js, ToolService.js (PTC block). Then remove the UI as in option A.

C — Keep the UI but explain the split. Label the field as "legacy tool only; bash_tool uses server env." Ugly and confusing.

Recommend B — it's the principled finish to the Phase 4 direction. A is acceptable if per-user keys have no remaining legitimate use case.

Scope of a fix (option B sketch)

Files with residual per-user EnvVar.CODE_API_KEY lookups:

• api/app/clients/tools/util/handleTools.js (CodeExecutionTool)
• api/server/controllers/agents/callbacks.js (file download callbacks)
• api/server/controllers/tools.js (tool auth config)
• api/server/routes/files/files.js / api/server/services/Files/process.js (sandbox uploads)
• api/server/services/ToolService.js:~1253 (PTC block)
• packages/api/src/tools/classification.ts (PTC classification)
• Frontend: remove useAuthCodeTool.ts + the install UI surface that calls it.

None of these are inside Phase 4's scope, so they deferred intentionally — but the UI drift is the kind of thing that silently rots.