Cogway talks to an unofficial Notion private API and authenticates with the token_v2 browser session cookie. That cookie grants everything the signed-in Notion account can do — not just Notion AI — and must be treated like a password.

• token_v2, full browser cookies, account JSON files, or screenshots of them
• .env and its MCP_PATH_SECRET
• ~/.notionagents/ — sessions, thread state, pool-state.json
• .runtime/, logs, or the *.cogway-backup-* copies of your editor configs

Add sessions with cogway login, which pipes the token straight into notion-agent init --token-v2 - from standard input, so it never reaches your shell history or the process list.

The bridge has no authentication. Anything that can reach its port can spend your Notion AI quota and read whatever the local tools can read. Keep COGWAY_BRIDGE_HOST=127.0.0.1 and do not port-forward it — cogway doctor reports a problem if the bridge is bound anywhere else.

Narrow CODE_ROOT to a projects directory if you do not want file tools to reach your whole home folder.

CODE_ROOT is not a sandbox. It bounds list_files, read_file, write_file and edit_file. It does not bound run_shell, which is exactly what it says it is: a native shell command with your user's privileges, able to read and write anything you can, wherever it lives. CODE_ROOT only sets that command's working directory. Two smaller consequences of the same design: a symlink inside CODE_ROOT that points outside it is followed, and the path check runs before the filesystem is touched. If you want a real boundary, run the local-tools server in a container or a VM, or leave COGWAY_LOCAL_TOOLS off — which is the default — and let your coding client provide the tools and the approval prompts instead.

Deleting a token in a later commit is not enough — it stays in history.

1. Sign out of Notion in the browser. That invalidates token_v2 immediately.
2. Sign back in and run cogway login to store a fresh session.
3. If the value was ever committed, purge it from Git history before publishing.

Before publishing a fork, run:

node scripts/check-public-release.mjs
git status --short

Use GitHub's private vulnerability reporting / Security Advisory feature. Do not include live credentials, cookies, private pages or user data. If private reporting is unavailable, open an issue with a minimal redacted description and ask for a private channel.