Extract into a shared config_redaction.cjs and require it from both files:

// config_redaction.cjs
function isSensitiveConfigKey(key) {
  return /token|secret|key|password|credential|private/i.test(key);
}
function redactSensitiveConfig(value) { ... }
module.exports = { redactSensitiveConfig };

// In both safe_outputs_config.cjs and safe_output_handler_manager.cjs
const { redactSensitiveConfig } = require('./config_redaction.cjs');

This is already a two-file inconsistency: safe_outputs_config.cjs extracts isSensitiveConfigKey as a named helper while safe_output_handler_manager.cjs inlines the regex. Centralising removes the surface area for divergence.

Add a test in safe_output_handler_manager.test.cjs (or a new file) that:

1. Sets GH_AW_SAFE_OUTPUTS_HANDLER_CONFIG to a JSON object containing a github-token field.
2. Calls loadConfig().
3. Asserts the logged output contains ***REDACTED*** and does not contain the real token value.

This mirrors the test added in safe_outputs_config.test.cjs and closes the coverage gap for this second log path.

Extract to a shared helper module (e.g. config_utils.cjs) and require it from both files. A future change to the redaction pattern (e.g. adding password or secret) would then need to be made in only one place, and a single test suite covers both call-sites.

Broaden the pattern in isSensitiveConfigKey (and mirror it in safe_output_handler_manager.cjs):

function isSensitiveConfigKey(key) {
  return /token|secret|key|password|credential|private/i.test(key);
}

Without this, a handler config like { "github_app_private_key": "...", "client_secret": "..." } will appear verbatim in Actions runner debug logs, potentially captured by log-forwarding or audit infrastructure. Token-only redaction is the most obvious case but far from the only one.

All GitHub Actions secret/input env vars generated by the Go compiler (WRITE_PROJECT_PAT, GH_AW_INPUT_*) are uppercase, so this isn't a current bug. But the restriction is invisible to callers and would cause a silent runtime failure if a lowercase or mixed-case placeholder ever appeared in a config.

Either document the uppercase-only contract with a comment, or broaden the regex to [A-Za-z_][A-Za-z0-9_]* to be defensive:

return value.replace(/\$\{([A-Za-z_][A-Za-z0-9_]*)\}/g, (match, envName) => process.env[envName] ?? match);

Consider logging a warning (or throwing) when a placeholder cannot be resolved:

return value.replace(/\$\{([A-Z_][A-Z0-9_]*)\}/g, (match, envName) => {
  if (process.env[envName] === undefined) {
    server.warning?.(`Placeholder ${match} has no matching env var — it will be passed literally`);
  }
  return process.env[envName] ?? match;
});

A companion test case for the unresolved-placeholder path would help pin the intended behaviour.

Emit a warning (or throw for required fields) when a placeholder remains unresolved:

return value.replace(/\$\{([A-Z_][A-Z0-9_]*)\}/g, (match, envName) => {
  const resolved = process.env[envName];
  if (resolved === undefined) {
    // Warn so operators see which variable was missing
    server?.warning?.(`Config placeholder ${match} is unset — passing through literally`);
  }
  return resolved ?? match;
});

Without this, a misconfigured workflow (missing secret binding) produces no startup error — the safe-outputs server starts, then fails later when it tries to authenticate with the literal string ${WRITE_PROJECT_PAT} as a token, which is extremely hard to diagnose.