🛡️ Sentinel: [MEDIUM] Fix local info disclosure and stack trace leaks

[parvezk]

🚨 Severity: MEDIUM

💡 Vulnerability:

1. Local Information Disclosure: The CLI tool stores session data (which might contain sensitive information like authentication metadata or tool execution outputs) in a local ~/.polyagent/state.json file. It was created using default permissions, meaning depending on the OS's umask, it could be globally readable by other users on the system.
2. Information Leakage via Errors: The main CLI script used program.parseAsync() but lacked a .catch() block. Unhandled exceptions (such as API keys missing, or internal runtime errors) would dump a full Node.js stack trace, exposing internal repository paths and potentially other context to the terminal.

🎯 Impact:

• Local users on a shared machine could potentially read sensitive CLI state data.
• Attackers or users encountering an error would see verbose stack traces instead of a secure, handled error message.

🔧 Fix:

• Updated src/state.ts to enforce 0o700 permissions on the ~/.polyagent directory and 0o600 on the state.json file.
• Appended a .catch() block to src/cli.ts's parseAsync() call that prints a clean, controlled error message and exits with a 1 code, without the stack trace.

✅ Verification:

• Ran npm test successfully (0 failures).
• Executed npx tsx src/cli.ts dispatch "test" --vendor claude without an API key to verify that the CLI prints a clean Error: message without dumping the stack trace.

---

PR created automatically by Jules for task 11128578396142026876 started by @parvezk

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
polyagent	Ready	Preview, Comment	Jul 27, 2026 9:01am

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 69370d4224

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Tighten permissions on pre-existing state files

When upgrading an installation that already has a permissive state.json—the population exposed by the vulnerability being fixed—writeFileSync opens the existing inode and ignores the supplied creation mode, so a 0644 or 0666 file remains readable after every save; similarly, mkdirSync(..., { recursive: true }) does not tighten an existing directory. Explicitly change existing permissions with chmod/fchmod, or securely replace the file, so the fix protects existing users rather than only newly created stores.

Useful? React with 👍 / 👎.