Must an agent know a filesystem path before it can use a file? In my browser, a person-selected asset becomes a handle and a task receives only the IDs it is allowed to use. I wanted convenient reuse without quietly granting access to files belonging to other work.
Registered files differ from the files selected this time
TaskFiles.add checks a real file and retains its name, size, path and modification time internally. Its return value contains IDs for the files supplied in this call, not every asset ever registered. An earlier image must not silently enter a later article just because the registry still knows it.
An unchanged path, size and modification time within the same profile reuse a handle. Repeatedly requesting one asset should not consume twenty distinct selection slots. Another profile gets another handle even for the same path. Windows path comparison accounts for case, but this metadata-based reuse rule is not a complete content-identity proof. Actual hashing belongs to the description step.
The selection limit should not leave a partial registration
Add accumulates new entries in pending and checks the limit together with existing entries for the profile before committing them. A request containing twenty-one distinct files must not register its first portion and then fail. Otherwise the caller sees failure while the registry silently retains an unexpected partial selection.
Reusing existing assets does not enlarge pending, and duplicate selected IDs are removed from the returned list. The useful property is an explainable state transition, rather than the particular number twenty. Refusal should leave no newly committed selection from that call. This registration step does not delete the files on disk; registry membership and filesystem ownership remain separate responsibilities.
Knowing an ID does not bypass the task grant
Describe and upload check both profile ownership and membership in the allowed ID list for the running task. Task-controller derives that list from scope.files. It would misdescribe the implementation to say TaskFiles directly accepts a project argument and independently resolves every project permission.
Describe checks file type, size and modification time before and after streaming its hash, with cancellation checks during the read. Returned fields are ID, name, size and SHA256; no filesystem path is exposed. Reducing path disclosure complements authorization, but does not replace it. Likewise, this metadata recheck should not be described as a universal defense against every possible concurrent filesystem substitution.
Recheck selection lifetime immediately before dispatch
Upload checks current metadata before handing files to the driver, and its pre-dispatch callback checks that each handle still refers to the same registry entry and file state. The placement matters: a revoked selection or changed asset should not continue under an old ID simply because an earlier check passed.
The driver-returned names and sizes are compared exactly with the expected list. A verified selection receipt explicitly says server transmission needs page-result verification. A visible name, server receipt and final article placement are different evidence. Without the later observation, an earlier successful stage must retain its narrower meaning. The operation does not infer remote byte identity merely from matching metadata.
Share a smaller permission experiment with explicit limits
The shared synthetic module stores supplied bytes rather than reading paths. It offers an explicit profile/project Scope, allowed IDs, revocation and equal-size content changes. This is an independent model for understanding profile registration and task grants, not a copy of the operational native picker.
I read the original unit cases for repeated registration, atomic refusal at the selection limit and changed-file upload rejection. I did not newly run the original browser for this article. The synthetic package has separate local and extracted-ZIP tests. Its documentation lets a reuser see which checks inspect actual supplied bytes and which accept caller declarations, so the evidence boundary remains visible during integration.