Christian Brauner
a12868399b
Index the pull request before the review and hand the index to the agents through semcode's MCP server. The first indexing run covers the files at the head. The second covers the range from the merge base, which adds the versions of the changed files at every commit of the pull request and at the merge base, and the commits themselves. The agents can then look at a function before and after the pull request with git_sha, and at the commits with find_commit. On a runner this takes about a minute. A review without the index is still a review, so a failed indexing run only logs. semcode-index parses the pull request and semcode-mcp runs outside the Claude Code sandbox, so both get a bubblewrap sandbox of their own: every file read-only but the index, nothing under /run, no network, none of the job's environment, gone with the agent. A read-only bind does not stop a connect, and the docker socket lives in /run. Each agent gets a server of its own, and no server runs when the sandbox does not work or the server does not answer a probe, so the agents are never pointed at tools that do not exist. The index is complete for the commit the checkout is at, so the indexing pass semcode-mcp runs at startup has nothing to write. The server files live in $RUNNER_TEMP, which the agent sandbox denies writes to, so a sandboxed shell cannot swap the server. Each call to a server has a time limit of two minutes. Without one, Claude Code waits half an hour for a stdio server, longer than the agent has, and a single runaway query would cost the whole lens. The server is not told and finishes the query anyway, but it answers requests concurrently, so the next call does not queue behind it. A lens whose every semcode call failed is treated like one whose every Bash call failed: its result is dropped. Calls a hook denied and calls that ran into the time limit are left out of that. The numbers of semcode calls, timeouts, grep calls and hook denials are printed for each lens, so we can see how much searching still bypasses the index.
System and Service Manager
Details
Most documentation is available on systemd's website.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS, and also repositories with packages built from the latest stable release