Skip to content

[Story]: Document the fork divergence and set an upstream-sync policy #2

Description

@stephane-segning

Summary

This repository is a fork of ClickHouse/code-interpreter carrying real first-party patches — the nsjail mount handling, the /usr/sbin independent-mount fix, the shared-library closure copy, faithful session-workspace failure reporting — plus our own CI publishing to ghcr.io/adorsys-gis. It is actively maintained and was synced with upstream on 2026-08-13. None of that is written down anywhere, and the repo has never had a single issue.

Intent / Source of truth

Surfaced by the 2026-08-13 cross-repo backlog consolidation. An actively-diverging fork with no stated policy is a known way to lose work: the next person to sync cannot tell which local commits are deliberate patches and which are stale, and a careless merge silently reverts a production fix. The sandbox patches here are security-relevant, which raises the cost of getting that wrong.

Scope

  • Document in the README that this is a patched fork, what it powers (the LibreChat code interpreter in librechat-sandbox), and where its images publish.
  • List the first-party patches carried on top of upstream and why each exists.
  • State an upstream-sync policy: how often, who verifies, and what smoke test must pass before the merge lands.
  • Decide the endgame for each patch — upstream it, or accept it as a permanent local divergence.

Out of scope

  • Rewriting or re-architecting the interpreter itself.

Verification

A reader unfamiliar with the repo can answer, from the README alone: why we forked, what we changed, and how to sync safely.

Risk assessment

The status quo is the risk. Doing nothing means the divergence rationale lives only in commit messages and one person's memory.

AI Usage Declaration

Drafted with AI assistance during the 2026-08-13 cross-repo backlog consolidation. A human owns intent, verification and consequences.

Metadata

Metadata

Assignees

No one assigned

    Labels

    user-storyA user need with testable acceptance criteria

    Type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions