nightshift: logging-audit — 127 console.* calls, no structured logging, sensitive data in logs

[nightshift-micr]

Logging Quality Audit — opencode-studio

Summary

127 console.* calls across the codebase. No structured logging library is used anywhere — everything relies on raw console.log, console.error, and console.warn. There is no log level configuration, no log format standardization, and no production vs development mode distinction.

Breakdown by Severity

🔴 Critical (5)

1. Sensitive data in server logs — server/cli.js:50 logs URL params from protocol actions (console.log('Params:', params)). Protocol URLs may contain tokens or auth data that gets written to stdout/stderr.

2. Auth flow debug logging in production — server/index.js lines 2785, 2797, 3001, 3067, 3075, 3079, 3081, 3159, 3431, 3491, 4348 contain verbose [Auth] debug logs that fire in production. These log internal paths, profile directories, namespace flags, and file existence checks.

3. No error context in client catches — client-next/src/app/commands/page.tsx:47 and client-next/src/app/mcp/page.tsx:42 do console.error(err) with no context string. When these fire, there's no way to know which operation failed.

4. Silent .catch(console.error) pattern — client-next/src/app/settings/page.tsx:83,94 use .catch(console.error) which logs but never surfaces the error to the UI. Users get no feedback when getPaths() fails.

5. 4667-line server/index.js with 58 console calls — This monolithic file makes logging impossible to grep, filter, or route. All subsystems (auth, backup, config, skills, MCP, plugins, terminal) share the same flat logging namespace.

🟡 Warning (8)

6. No log levels — There's no way to distinguish debug/info/warn/error severity. console.log('[Auth] ...') is debug-level, console.error('Usage API error:') is error-level, but both go to the same channel with no filtering.

7. Inconsistent error logging in client — Some catches log console.error("Failed to X:", e) (good — has context), others log console.error(e) (bad — no context). Affected: commands/page.tsx:47, mcp/page.tsx:42, usage/page.tsx:177, context.tsx:110.

8. Duplicate logging across client/server — [AutoSync] logs appear in both server/index.js:2251-2258 and client-next/src/lib/context.tsx:147. Client logs sync state but server already handles it.

9. No request correlation — Server logs have no request ID, session ID, or correlation token. With concurrent requests, logs from different users interleave unpredictably.

10. LogWatcher quota logging at wrong level — server/index.js:302,312,322,336,339 use console.log for quota exhaustion and rotation events. These are operational warnings that should be at warn level.

11. Terminal command logging leaks info — server/index.js:3220,3230,3259 log full terminal commands being executed, which may contain paths, arguments, or credentials.

12. Missing structured fields — Server [Auth] and [AutoSync] prefix strings are the only "structure". No timestamps, no subsystem tags, no machine-readable format.

13. Profile migration logged as info — server/profile-manager.js:26 logs a migration event with console.log but this is a one-time operation that deserves warn level (data migration is risky).

🟢 Info (5)

14. Protocol registration logging is fine — server/register-protocol.js uses appropriate console.log/error for a CLI tool startup sequence.

15. Template strings in add-plugin-dialog.tsx — The 30 console.log calls in this file are inside template literal strings (plugin code examples shown to users). These are NOT runtime logs — they're documentation. No action needed.

16. Startup "Server running" message — server/index.js:4611 is appropriate CLI startup logging.

17. OAuth callback server port — server/index.js:4393 is useful for debugging.

18. dev-with-port.js — Development-only script, logging is expected.

Recommendations

1. Adopt a structured logger — Replace console.* with a library like pino (fast, JSON output) or winston (flexible transports). Even a thin wrapper (const logger = { debug, info, warn, error }) would enable level-based filtering.

2. Add LOG_LEVEL env var — Let users control verbosity. Default to info in production, debug in development.

3. Redact sensitive fields — Auth paths, profile directories, and URL params should not be logged at info level. Use a redaction pattern for anything containing token, key, secret, password.

4. Add request IDs — Express middleware can assign a UUID per request. Include it in every log line for the request lifecycle.

5. Surface client errors to UI — Replace .catch(console.error) with proper error state updates. Users need toast notifications or error boundaries, not silent console logs.

6. Split server/index.js — Extract auth, backup, config, skills, MCP, plugins, and terminal into separate modules with their own logger instances (logger.child({ module: 'auth' })).

Files Analyzed

File	Console Calls	Issues
server/index.js	58	Critical: auth debug logging, no levels, no correlation
client-next/src/components/add-plugin-dialog.tsx	30	None (template strings, not runtime)
server/cli.js	10	Critical: logs URL params
server/register-protocol.js	6	Low: appropriate CLI logging
client-next/src/app/auth/page.tsx	6	Warning: no user feedback on errors
server/profile-manager.js	1	Info: migration log level
client-next/src/app/settings/page.tsx	3	Critical: silent catch
client-next/src/app/usage/page.tsx	2	Warning: no context on error
client-next/src/lib/api.ts	2	Low: adequate error logging
client-next/src/lib/context.tsx	2	Warning: duplicate sync logging
Other files	7	Low

---

Generated by nightshift — logging-audit task