screenpipe-gateway 企业查询网关部署指南：写只读归档、离线令牌认证与访问审计

screenpipe-gateway 企业查询网关部署指南写只读归档、离线令牌认证与访问审计【免费下载链接】screenpipeYC (S26) | Open Computer History | Record your screen continuously locally and provide context to your agents (Claude, Codex, Openclaw, Hermes, Runner...)项目地址: https://gitcode.com/GitHub_Trending/sc/screenpipe本指南面向需要**自行运行 screenpipe 企业查询网关query gateway**的运维与安全工程师完整讲解从容器拉取、环境变量配置、AWS/MinIO 存储接入到签名策略signed policy离线认证、访问日志审计、故障排查与容量规划的整套实战流程。读完本文你将掌握如何在自有基础设施上安全地部署这个唯一读取归档的查询入口并理解其写只读信任模型下的每一个安全边界。本文以 crates/screenpipe-gateway/README.md 为骨架结合本仓库源码逐项印证实现细节。一、先理解信任模型为什么网关是唯一的读取主体screenpipe 的桌面端会持续在本机录制屏幕与音频并把 OCR 文本、转写内容等批量上传到客户自有的 S3 兼容对象存储桶archive bucket。Screenpipe 侧只持有写权限s3:PutObject从不给自己配置回读路径而网关gateway正是唯一被授权读取该归档的组件——明文索引、查询日志、搜索结果全部落在你控制的基础设施上。从 Cargo.toml 的描述可以看到该 crate 的定位Customer-run query gateway: polls the write-only telemetry archive bucket, ingests batches into SQLiteFTS, and serves the enterprise v1 REST surface inside the customers network.即轮询只写归档桶 → 将批次摄入 SQLiteFTS 索引 → 在客户网络内部提供 enterprise v1 REST 接口。本文只讨论如何跑这个容器关于信任模型的完整论证为什么归档是只写的、签名策略包含什么、Screenpipe 能/不能看到什么README 明确指向了网站仓库的信任模型文档属于设计文档范畴不在本文展开。二、部署前置条件四条红线先读再动手前置条件说明归档桶绝不能公开在归档桶上开启 S3 Block Public Access或你所用云厂商的等价能力最好在账号级开启。一个世界可读的桶会摧毁整个模型而且拒绝金丝雀denial canary不会提醒你——它使用 Screenpipe 的只写凭据探测验证的是我们Screenpipe读不了对匿名访问是否开放一无所知。这是唯一一种会悄悄把只写归档变成公开归档的误配置。网关端口必须私有网关二进制只提供明文 HTTP完全没有 TLS 支持见第七节。必须把它绑定在只有你自己的客户端和反向代理能触达的位置。索引是明文且属于你gateway.db包含你整个设备群上传内容的解码明文——OCR 文本、转写、记忆见第六节。加密卷、是否备份、何时清除都由你决定。Screenpipe 无法访问它也无法替你清除仪表盘里的POST /api/enterprise/storage/wipe只清托管侧元数据和托管对象刻意不触碰客户自有存储与本索引。时钟纪律签名策略带有效窗口。主机时钟偏差超过几分钟每次查询都会 503。必须运行 NTP。源码层面配置解析器 config.rs 明确实现了空字符串即未设置的规则blank values read as unset并且必填变量缺失时直接返回GatewayError::Config这正是 README 所说硬性启动错误hard boot errors的实现。三、容器镜像拉取、校验与自建公开镜像位于公共 registry无需 registry 凭据、IAM 配置或白名单docker pull ghcr.io/screenpipe/screenpipe-gateway:0.4.29务必钉住版本最好钉住 digest。:latest会漂移。GHCR 没有不可变标签设置版本标签只能靠发布策略保护发布任务拒绝覆盖已存在的标签而非 registry 本身。digest 是唯一无法被重新指向的引用docker pull ghcr.io/screenpipe/screenpipe-gatewaysha256:digest每一份发布的镜像都携带签名构建溯源证明signed build provenance attestation把该 digest 绑定到产生它的 workflow run 与 commit。部署前请校验gh attestation verify oci://ghcr.io/screenpipe/screenpipe-gateway:0.4.29 \ --repo screenpipe/screenpipe自行构建同样完全支持——源码公开且构建不需要任何密钥# Build context 是 REPO ROOT——需要工作区清单 docker build -f crates/screenpipe-gateway/Dockerfile -t screenpipe-gateway .镜像内部结构来自 Dockerfile基础镜像选debian:bookworm-slim约 75MB而非静态 musl/scratch 镜像依赖闭包恰好只有一个 C 依赖内置 SQLite sqlite-vec而sqlite-vec0.1.3 在 musl 下无法编译。镜像自带ca-certificatesTLS 到 S3 与控制平面和curl健康检查以非 root 用户screenpipe运行EXPOSE 3040。uid/gid 固定为 999:999与面向客户的 Fargate 模板中 EFS access point 的 PosixUser 保持一致。发布镜像只含一个二进制screenpipe-gateway不带任何配置所有凭据都在运行时通过环境变量注入见第四节。compose 演示用的合成设备播种器seeder与策略签名 fixture 属于测试专用位于单独的--target e2e镜像中永不发布——seeder 会写入归档桶绝不能指向生产环境。镜像目前是linux/amd64在 Graviton/arm64 主机上暂时需要自行从源码构建。四、配置全部旋钮都是环境变量12-factor无配置文件配置解析集中在 config.rs 的GatewayConfig::from_lookup。缺失必填变量、任何配错的认证姿态都会导致硬启动错误——网关拒绝在半配置状态下运行。必填变量含义SCREENPIPE_GATEWAY_LICENSE_ID你组织的 license id。对象键内嵌它enterprise-telemetry/{license_id}/…每次查询的租户范围由该值推导而非由策略推导——见第八节。SCREENPIPE_GATEWAY_S3_BUCKET归档桶。认证姿态三选一见第八节变量含义SCREENPIPE_GATEWAY_POLICY_PUBKEY_B64Base64 编码的 ed25519 公钥钉住策略签名者。设置它即开启 bearer 认证。从GET /api/enterprise/gateway/policy-key获取。SCREENPIPE_GATEWAY_CONTROL_PLANE控制平面 origin如https://screenpi.pe开启 enroll → 策略拉取 → 心跳循环。…_CONTROL_PLANE_BASE是接受的别名两者都设置时规范名优先config.rs 中有专门测试the_control_plane_base_alias_is_accepted_and_loses_to_the_canonical_name保证这一点。SCREENPIPE_GATEWAY_ENROLLMENT_TOKEN短 TTL、单次使用的sge_令牌在仪表盘网关面板中铸造。仅首次启动需要——它换来的长期凭据会被持久化第六节下次重启时该令牌按设计已过期。SCREENPIPE_GATEWAY_POLICY_PATH有控制平面时冷启动缓存拉取结果原子写入因此控制平面故障期间重启仍能带着最后已知良好策略启动。无控制平面时策略来源每个轮询间隔重新读取气隙/运维托管姿态。SCREENPIPE_GATEWAY_CONTROL_PLANE_ALLOW_HTTP1/true允许非回环主机上的明文http://控制平面。默认关闭且每次启动都会记一条 ERROR明文下长期sgw_凭据会在每次拉取与心跳中裸奔路径上的攻击者可替换策略信封。回环地址无需此逃生舱config.rs 测试要求只有1/true能开启0/false/no/拼写错误一律保持关闭。存储变量默认值含义SCREENPIPE_GATEWAY_S3_ENDPOINTAWSS3 兼容存储MinIO、R2的自定义 endpoint。SCREENPIPE_GATEWAY_S3_REGIONus-east-1—SCREENPIPE_GATEWAY_S3_ACCESS_KEY_ID/…_SECRET_ACCESS_KEY未设置静态凭据。在 AWS 上两者都保持未设置——此时 provider chain 会拾取 task/instance role即第四节描述的姿态。SCREENPIPE_GATEWAY_S3_ALLOW_HTTP关闭允许明文http://endpointcompose 中的 MinIO。SCREENPIPE_GATEWAY_KEY_PREFIX未设置存储绑定可选的前缀。API 可见的键永不包含它。SCREENPIPE_GATEWAY_DATA_DIR/data索引、快照、凭据与策略缓存存放处第六节。必须是持久卷。节奏与绑定变量默认值说明SCREENPIPE_GATEWAY_BIND0.0.0.0:3040明文。见第七节。SCREENPIPE_GATEWAY_POLL_SECONDS30S3 摄入节奏——多久拾取一次新批次。下限 1s设 0 会让 LIST 循环忙转。这不是策略节奏混淆两者会把策略刷新频率提高 10 倍。config.rs 中MIN_POLL_SECONDS 1并对0做了 floor。SCREENPIPE_GATEWAY_HEARTBEAT_SECONDS60向控制平面汇报存活与游标。下限 1s。config.rs 注释解释了原因tokio::time::interval对零周期会panic而该 panic 发生在被派生的控制平面任务内部会悄悄杀死策略刷新——因此专门有测试a_zero_heartbeat_cadence_is_floored_not_passed_to_tokio守护这个下限。SCREENPIPE_GATEWAY_POLICY_REFRESH_SECONDS未设置正常情况保持未设置。节奏来自控制平面通告的policy_refresh_seconds300s。下限 30s上限为策略有效窗口的一半。RUST_LOGinfo,sqlxwarninfo会输出每条查询的访问日志第九节。关于布尔旋钮的统一规则config.rs 中env_flag的实现是1/true任意大小写为开其余一切包括0、拼写错误为关所有布尔开关共用一套形状。五、AWS 部署角色、桶策略与任务定义不要手搓这套配置。网关所需的 IAM 角色只读访问你归档前缀下恰好那部分、桶策略、以及可用的 ECS/Fargate 任务定义在网站仓库的docs/gateway-aws-role.mdSCR-293中是一键 CloudFormation 流程的单一事实来源。保持SCREENPIPE_GATEWAY_S3_ACCESS_KEY_ID/…_SECRET_ACCESS_KEY未设置以便使用任务角色。最小权限原则网关需要的仅仅是归档桶上的s3:GetObjects3:ListBucket仅此而已。Screenpipe 侧持有的只是只写s3:PutObject凭据。六、MinIO / 本地部署 / 其他 S3 兼容存储供应商中立是刻意设计S3 设置只镜像任何 S3 兼容部署所需不多不少。因此非 AWS 部署是手动配置路径——一键模板仅限 AWS。一份可直接工作的配置逐字取自 compose 测试环境e2e/docker-compose.ymlenvironment: SCREENPIPE_GATEWAY_LICENSE_ID: lic-e2e SCREENPIPE_GATEWAY_S3_BUCKET: screenpipe-archive SCREENPIPE_GATEWAY_S3_ENDPOINT: http://minio:9000 SCREENPIPE_GATEWAY_S3_REGION: us-east-1 SCREENPIPE_GATEWAY_S3_ACCESS_KEY_ID: screenpipe SCREENPIPE_GATEWAY_S3_SECRET_ACCESS_KEY: screenpipe-e2e-secret SCREENPIPE_GATEWAY_S3_ALLOW_HTTP: 1 # plain http to MinIO SCREENPIPE_GATEWAY_DATA_DIR: /data SCREENPIPE_GATEWAY_BIND: 0.0.0.0:3040 volumes: - gateway-data:/data真实本地部署的注意事项为网关铸造一个只读用户。Screenpipe 只持有只写s3:PutObject凭据网关需要的是归档桶上的s3:GetObjects3:ListBucket别无其他。S3_ALLOW_HTTP1只用于私有网络。明文下归档批次——也就是内容本身——在网络上裸奔。MinIO 需要 path-style 寻址上面的 endpoint 形式已自动选择。拒绝金丝雀从控制平面针对你的 endpoint 运行。如果你的 MinIO 从控制平面不可达金丝雀报告error而非pass网关会停留在registered状态而不会翻转为active。从 e2e 配置可以看到完整的演示链路minio扮演客户只写归档桶→create-bucket用mc建桶 →seed扮演两个只写模式的桌面设备→gateway客户运行的查询网关轮询间隔被调成 2s 便于演示。入口脚本是 e2e/run.sh另有带认证姿态的 e2e/docker-compose.auth.yml。七、磁盘上的状态以及如何清除所有内容都位于$SCREENPIPE_GATEWAY_DATA_DIR/data下路径是什么如果删除gateway.db-wal、-shmSQLite 索引每条摄入记录的解码明文加上其上方的 FTS 索引加上gateway_ingested_objects记账表。网关会在下一次轮询时从 S3 重新摄入整个归档。无数据丢失但会完整重读并重新下载整个桶。snapshots/从批次中提取、由/frames/{device}/{frame}提供的帧图。这些帧在重新摄入前 404。gateway-registration.json长期sgw_控制平面凭据权限0600。网关将无法心跳或拉取策略且无法自行重新注册必须在仪表盘铸造新的 enrollment token。不要在不同网关间复制该文件——每次/register都会吊销上一个网关行。policy.json若设置了POLICY_PATH已验证的策略信封用作冷启动缓存。无害下次拉取会重写它。但控制平面故障期间的重启将无缓存可回退。清除索引明文索引属于你所以清除它是一次不涉及 Screenpipe 的本地操作# compose 方式 docker compose stop gateway docker volume rm project_gateway-data # 例如 e2e_gateway-data docker compose up -d gateway # 或保留凭据、免去重新注册 docker compose exec gateway sh -c rm -rf /data/gateway.db* /data/snapshots docker compose restart gateway有两点必须清楚这不会删除归档桶里的任何内容。桶是系统的记录源system of record网关会从中重新摄入。要真正移除内容你必须按自己的生命周期策略删除自己桶里的对象。仪表盘的存储清除按钮不触碰这里。它只清托管元数据行和托管对象客户自有存储与本索引明确不在其触及范围内。八、TLS二进制只有明文该二进制是纯明文。它绑定一个普通 TCP 监听器并提供 HTTP没有 TLS、没有证书配置、没有https模式。这不是一个可以绕过的疏漏而是一个必须满足的部署要求在它前面终结 TLS带 ACM 证书的 ALB/NLB、nginx/Caddy/Envoy或 service mesh sidecar。客户端指向代理。让网关本身无法被其他东西触达——SCREENPIPE_GATEWAY_BIND127.0.0.1:3040并在同一主机放代理或使用只允许代理进入的安全组/网络策略。不要向你不控制的网络发布 3040 端口。它服务的所有内容——搜索结果、记录文本、通过/files/{key}返回的原始归档对象——都是明文归档内容。如果跳过这一步失败是无声的一切工作正常而你整个设备群的屏幕文本正以未加密状态穿过你的内网。九、认证姿态与策略新鲜度/故障的权衡三种姿态中间那种是试点pilot应该跑的姿态环境变量行为控制平面随发布提供POLICY_PUBKEY_B64CONTROL_PLANE首次启动加ENROLLMENT_TOKEN注册一次按通告节奏拉取并验证签名策略心跳上报真实摄入游标。仪表盘的吊销在一个刷新周期内到达网关。运维托管文件POLICY_PUBKEY_B64POLICY_PATH无控制平面文件是来源每个轮询间隔重读。适用于气隙部署。你有责任投递新鲜信封——陈旧文件会失败关闭fail closed且该姿态下时钟偏差无法诊断。未认证M1 演示两者皆无每个/api/enterprise/v1/*路由都无令牌应答。网关每次启动都会把它记为 ERROR。只在完全受控的私有网络上、且仅用于演示时才可以接受。只设置POLICY_PUBKEY_B64而没有控制平面或策略路径是启动错误网关不会去猜认证姿态。这一逻辑在 main.rs 中直接体现POLICY_PUBKEY_B64已设置但CONTROL_PLANE/POLICY_PATH皆无时直接return Err(...)——refusing to guess an auth posture。权衡两个窗口有两个窗口共同决定暴露面——刷新节奏吊销的令牌还能用多久与策略有效窗口控制平面故障能持续多久而网关仍继续服务。缩短一个就会加长对另一个的暴露。规范值、理由与环境变量覆盖README 明确刻意不在本文重复安全窗口的副本多一份都是浪费而是指向网站仓库与信任模型文档。网关如何使用它们是本文该说的部分策略超过有效窗口 →每个受作用域路由 503对所有令牌。失败开放fail open意味着在为一个已过期授权列表服务这无法证明此后的任何吊销。策略签发于未来、或在到达时因时钟与签名者不一致而过期 → 仍然 503但消息点名NTP而非暗示控制平面故障。失败的刷新会保留上一份文档。一次坏的拉取不是故障。为不同组织签发的策略即使验证通过也会被拒绝签名密钥跨租户共享所以有效签名只能证明 Screenpipe 签发了该信封。载荷的license_id才是全部租户绑定——因此第三节强调查询按SCREENPIPE_GATEWAY_LICENSE_ID划定范围。main.rs 的认证装配清晰可见设置policy_pubkey_b64时构造PolicyStore::new(cfg.license_id)绑定租户的存储随后ControlPlaneTask::boot完成注册→播种策略→武装刷新与心跳循环无控制平面时回退到文件姿态或大声报错。验证者摘要列表verifier digest list网关持有的签名策略包含你组织中每个活跃sk_ent_令牌的 SHA-256 摘要因此验证完全可以离线——无需对 Screenpipe 做每次查询的调用这正是整个设计的要点。这允许与不允许什么非加盐摘要、高熵令牌、轮换、以及未决的安全评审问题写在信任模型文档的 verifier digest 一节。信封格式在 policy.rs 中有完整 JSON 示例version、alg: ed25519、key_id、payload_b64、signature_b64签名覆盖解码后的原始载荷字节与 JWS 相同的构造完全绕开 JSON 规范化问题载荷为license_id、issued_at、valid_until、token_grants[]每个 grant 含digest、scopes、可选expires_at。认证中间件 auth.rs 实现了细节令牌形状合法性长度 16..4096、未知令牌 → 401invalid token、过期授权 → 401token expired、缺作用域 → 403 并列出已拥有作用域路由分类默认拒绝deny by default——只有PUBLIC_ROUTES/health、/version、/access-log允许免认证未分类的新路由会被 403 拒绝SCR-353 的回归防护。十、验证是否工作——以及访问日志健康与版本端点免认证/health、/version。然后GWhttp://127.0.0.1:3040 curl -sf $GW/health # 首次上传后的一个轮询周期内应出现设备 curl -sf $GW/api/enterprise/v1/devices -H authorization: Bearer $SK | jq curl -sf $GW/api/enterprise/v1/search?qroadmap -H authorization: Bearer $SK | jq每个 v1 请求都会在容器 stdout 产生一行访问日志在RUST_LOGinfo下2026-07-24T09:14:02.117Z INFO screenpipe_gateway::access_log: v1 query \ path/api/enterprise/v1/search scoperead:search status200 servedtrue \ token_digest_prefix9f2c1ab0 elapsed_ms7每请求一行上面为可读性折行。字符串字段带引号所以用grep 9f2c1ab0搜裸值而不是grep token_digest_prefix9f2c1ab0。颜色码只在 stdout 是终端时输出——日志文件或容器日志驱动会得到干净可 grep、可解析的纯文本。access_log.rs 中有专门测试no_binary_configures_tracing_by_hand守护这一点防止任何二进制绕过统一的init_tracing而把 ANSI 转义码带进日志。要点查询串刻意缺席——?q…是搜索者真正的搜索文本访问日志不是放它的地方。token_digest_prefix是sha256(token)的前 8 个十六进制字符与策略授权列表使用同一摘要方案。要把一行归属到某个令牌就用策略信封中的摘要对它做前缀匹配。日志永不持有凭据。把这些行送到你的日志汇log sink按自己的节奏保留。这就是谁读了归档的持久审计记录——Screenpipe 侧按构造没有等价物。两个scope值不是作用域。unmapped是没有匹配到作用域、因此在读令牌之前就被拒绝的路由not-served是托管专属表面/pipes、/workflows/generated以类型化 501 应答。两者都会被记录让探测留下痕迹并与read:*分开计数——二者永远不可能是归档读取合并计数会夸大你的归档被查询的量。机器可读摘要位于/access-logcurl -sf $GW/access-log | jq { process_started_at: …, queries_served: 412, queries_denied: 3, last_query_served_at: …, by_scope: { read:search: { served: 380, denied: 2 }, … }, reported_to_screenpipe: false }计数器是进程生命周期的重启即重置——日志行才是持久记录。该端点刻意免认证它正是你在认证不工作时策略过期、控制平面宕机、令牌被吊销需要的东西而恰恰在这些时候认证门后的计数器会读不到。它只携带聚合计数——无查询文本、无设备 id、无对象键、无令牌材料——但确实会向任何能触达端口的东西暴露网关有多忙这正是第一、七节要求你限制端口的原因。查询量永远不会发给 Screenpipe。心跳只携带摄入计数器看到/摄入/失败的对象、插入/去重的记录、不可解析的行与摄入游标——与查询无关。reported_to_screenpipe在该载荷中字面为false让评审者可以直接核查该声明而非相信它。access_log.rs 的模块注释说明了为什么审计日志与计数器是两个刻意分离的产物日志是持久记录计数器是进程内快照并解释了为何/access-log必须免认证故障时可用以及为何按作用域而非路径计数防止/files/*key这类调用者可控段导致内存无界增长的 DoS。十一、故障排查仪表盘的网关面板显示最近一次心跳的错误码。对照此表码含义首先检查什么E_S3_ACCESS_DENIED网关的凭据/角色读不了桶。角色在enterprise-telemetry/{license_id}/*上的s3:GetObjects3:ListBucket第五节。E_S3_LIST/E_S3_GET存储可达但调用失败。endpoint、region、path-style、网络出口。E_BATCH_PARSE对象不是合法线上格式。桌面应用版本偏差遗留加密对象会被跳过而非失败。E_DB_WRITE/E_DB_READ/E_SNAPSHOT_STORE本地磁盘。卷满或$DATA_DIR对screenpipe用户不可写。E_POLICY_FETCH策略拉取失败不可达、5xx、或控制平面签名密钥未配置。每个受作用域路由都在 503。每次心跳刻意重申。E_POLICY_REJECTED信封到达但验证失败或它为另一组织签名。POLICY_PUBKEY_B64与/api/enterprise/gateway/policy-key一致LICENSE_ID与策略一致。E_POLICY_STALE缓存策略老化超时。所有受作用域内容都在 503。控制平面可达性然后是时钟。E_POLICY_CLOCK_SKEW本机时钟与签名issued_at不一致。用date -u对照控制平面。运行 NTP。按症状排查症状原因容器启动即退出配置错误。读最后一行日志——每一行都会点名对应变量。每个查询都 503尚未安装策略或策略过期/未来日期。/health仍应答查启动日志与心跳码。每个查询都 401invalid token令牌不在当前授权列表中——被吊销或在上次刷新之后铸造。等一个刷新周期。403token lacks required scope看仪表盘 API-tokens 页里令牌的作用域。消息会列出它实际拥有的作用域。403route has no scope mapping你到达了本构建未分类的路径。不是配置问题——请上报。上传后/devices返回 0摄入尚未跟上一个轮询周期或桶/前缀/license id 与设备上传目标不匹配。状态卡在registered从不active激活需要心跳和通过拒绝金丝雀。从仪表盘运行金丝雀。十二、容量规划诚实声明我们未发布单设备-日per-device-day数字因为我们没有在真实设备群上测量过。两次合成设备本地运行得出的数字对真实部署会错上几个数量级而错误指导比没有更糟。能告诉你的只有形态以及如何测你自己的。CPU由摄入主导JSON 解析 SQLite 插入 FTS 分词在轮询间隔上是突发性的而非平稳的。搜索是本地文件上的 SQLite FTS5。单个小实例2 vCPU是合理的起点。内存由 SQLite 的页缓存和正在解析的批次大小主导。没有归档的内存索引。磁盘是关键的轴在你清除它之前无界增长第七节。两个贡献者规模差异很大记录文本小、可压缩、大致与你设备上传的 OCR/转写量成正比和snapshots/帧图——如果你的设备群上传快照它就是主导项。来自桶的网络出口在首次摄入时等于归档大小之后每次轮询是增量。在 AWS 上让网关与桶同区域。在真实流量跑一周后测你自己的# 索引与快照分开测——比值就是全部故事 docker compose exec gateway sh -c du -sh /data/gateway.db /data/snapshots # 这代表多少条记录看心跳计数器在仪表盘面板或直接从线上抓除以records_inserted和设备-日数你就得到你自己的设备群内容配比数字。据此设置卷并在它填满前规划清除或快照生命周期——E_DB_WRITE就是卷满的样子。十三、重启与升级网关可随时安全重启也可从全新镜像运行摄入对每个对象和每条记录都是幂等的与记账表原子提交因此批次中途崩溃会干净重放重复上传会合并。升级时保留$DATA_DIR。凭据在里头清除 重新注册索引也在里头清除 重读整个桶。不要对同一个DATA_DIR跑两个网关。它们会争夺 SQLite 文件而且每次/register都会吊销上一个网关行——它们会互相作废凭据。向前滚动升级不要对同一卷跑混版。十四、Screenpipe 能看到什么为完整性说明——这也是上面所有设计的原因。从你的网关我们只收到心跳版本、摄入游标、摄入计数器、错误码。没有查询、没有查询量、没有结果、没有内容。令牌生命周期铸造/吊销发生在仪表盘策略拉取按节奏而非按查询——所以我们的访问日志不携带你组织的任何按查询认证流量。你确实查询过的证据在你的侧第十节。完整的账目包括托管部分与托管审计表里的排序怪癖在信任模型文档中。而网关侧这条查询发生在这里而非 Screenpipe的正面证据链正是 access_log.rs 模块注释所说的positive control让Screenpipe 托管侧显示零内容读取这个声明变得可证伪、可验证——接受运行acceptance run需要客户侧的正向证据证明查询确实发生了而 Screenpipe 侧零感知。总结screenpipe-gateway 是这套写只读企业归档体系中唯一读取主体它以纯容器形态运行在客户网络内通过环境变量完成全部配置从 S3 兼容桶摄入明文批次到本地 SQLiteFTS 索引以离线验证的签名策略承载sk_ent_令牌认证并以一请求一行的访问日志把谁读了归档的审计记录完整留在客户侧。部署时记住四条红线——桶不公开、端口不公开、明文索引自管、时钟走 NTP——再按三种认证姿态选择适合自己的路径即可在生产环境中安全落地。深入阅读完整的代码与配置可从 crates/screenpipe-gateway/README.md、Dockerfile、e2e/docker-compose.yml 及 src/config.rs、src/main.rs、src/auth.rs、src/policy.rs、src/access_log.rs 入手端到端行为测试可参考 tests/binary_talks_to_the_control_plane.rs 与 e2e 一致性测试目录 e2e/conformance。【免费下载链接】screenpipeYC (S26) | Open Computer History | Record your screen continuously locally and provide context to your agents (Claude, Codex, Openclaw, Hermes, Runner...)项目地址: https://gitcode.com/GitHub_Trending/sc/screenpipe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考