# Repository hooks to inspect before trusting a GitHub project

> Source: <https://dev.to/harshitethic/repository-hooks-to-inspect-before-trusting-a-github-project-28p4>
> Published: 2026-10-18 03:59:03+00:00

Opening a folder, installing dependencies, attaching a coding agent, or launching a devcontainer can activate configuration-defined commands. Here is a short checklist for finding the known entry points before you decide what to trust.

Repository configuration can describe what a development tool *may* run later. Seeing a command in a file is not proof that it executed, that the author is malicious, or that the project is compromised. Triggers depend on individual package-manager, editor, trust and agent settings.

Review an unfamiliar checkout from a separate trusted terminal **before** installing its packages, opening it as a trusted editor workspace, or starting a coding agent. Even cloning is not a sandbox: your local Git configuration and environment may affect Git operations.

Look in `package.json`, especially the `scripts` keys `preinstall`, `install`, `postinstall`, `prepare` and `prepack`. Some package-manager operations can invoke these automatically. A normal lifecycle command is not inherently suspicious; check the script and the programs it calls.

```
{
  "scripts": {
    "postinstall": "node scripts/verify-setup.js"
  }
}
```

This is an **inert illustration**. Do not execute it to inspect it. ClonePeek models these npm surfaces and follows one statically identifiable hop into literal local `.sh` references, but it does not analyze arbitrary JavaScript imports or recursive script execution.

Inspect `.vscode/tasks.json` for tasks that declare `runOptions.runOn: folderOpen`. Whether a task runs when the folder is opened depends on workspace trust and automatic-task settings. Read the command, task arguments and referenced files before accepting the workspace.

```
{
  "version": "2.0.0",
  "tasks": [{
    "label": "Example setup task",
    "type": "shell",
    "command": "echo review-me",
    "runOptions": {"runOn": "folderOpen"}
  }]
}
```

The `echo` value is deliberately harmless; this snippet exists to demonstrate the configuration shape, not to perform a setup.

Review `.devcontainer/devcontainer.json` for `initializeCommand`, `onCreateCommand`, `postCreateCommand`, `postStartCommand` and `postAttachCommand`. Those correspond to different phases of creating, starting and attaching to a development environment. Devcontainer features can also introduce build-time setup. An isolated container is not a blanket guarantee of safety when it has mounts, credentials or network access.

Look at project files such as `.claude/settings.json` and `.claude/settings.local.json`. Command hooks can be attached to events such as `SessionStart` or `PostToolUse`. Activation depends on the agent and its configuration. Treat instructions, tools and automatic commands from a new project as untrusted until reviewed.

Look for `.cursor/hooks.json`, including event definitions such as `workspaceOpen` and `afterFileEdit`. Read *what will be invoked, when, and by which process*. A passive review tool should never trigger the hook merely to discover its output.

Review the local MCP configuration your agent or editor may consume, particularly each `mcpServers` entry with a `command`, `args`, environment variables and filesystem references. These are process-launch instructions, not necessarily running servers. They may take effect only when the client enables or approves them.

I maintain [ClonePeek](https://github.com/harshitethic/clonepeek), a small MIT-licensed Python CLI and GitHub Action for enumerating the modeled entry points above. The scan reads bounded configuration files and does **not** run the target repository's scripts. Downloading/installing the scanner itself uses a network connection; the scan itself operates offline.

```
uvx --from git+https://github.com/harshitethic/clonepeek@v0.5.1 clonepeek /path/to/repo
```

For an inert demonstration, use the bundled [agent-hooks fixture](https://github.com/harshitethic/clonepeek/tree/main/examples/agent-hooks). Review the **trigger** , source **path and line** , example **evidence** , and suggested review advice for each finding. None of the example commands needs to run.

You can also start with this non-blocking PR workflow:

```
name: Review execution hooks
on: [pull_request]
permissions:
  contents: read
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: harshitethic/clonepeek@v0.5.1
        with:
          path: .
          fail-on: none
```

The [Action integration guide](https://github.com/harshitethic/clonepeek/blob/main/docs/GITHUB-ACTION.md) explains thresholds, baselines, JSON/SARIF and changed-file mode.

Have a harmless repository hook that is missing or misclassified? A tiny inert reproduction and clear expected trigger help more than generic praise. The public [threat model](https://github.com/harshitethic/clonepeek/blob/main/docs/THREAT_MODEL.md) lists blind spots, and the [labeled synthetic evaluation](https://github.com/harshitethic/clonepeek/blob/main/docs/EVALUATION.md) is explicitly **not** independent real-world accuracy evidence.

[Contribute an inert field test ↗](https://github.com/harshitethic/clonepeek/issues/14) [Get the stable release ↗](https://github.com/harshitethic/clonepeek/releases/tag/v0.5.1) [Explore ClonePeek ↗](https://harshitethic.github.io/clonepeek/)

*Disclosure: I maintain ClonePeek. This DEV cross-post was prepared with AI assistance from my original, publicly available technical guide and is not an independent endorsement. See the repository threat model for the exact scan boundaries.*